Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: x/sys/unix: add support for vectorized ("scatter/gather") IO syscalls on Darwin #64710

Open
mschoenlaub opened this issue Dec 14, 2023 · 4 comments

Comments

@mschoenlaub
Copy link

mschoenlaub commented Dec 14, 2023

Proposal Details

The following syscalls could be supported on modern OSX versions (Darwin 11 and newer)

  • unix.Readv(fd int, iovs [][]byte) (n int, err error)
  • unix.Preadv(fd int, iovs [][]byte, offset int64) (n int, err error)
  • unix.Writev(fd int, iovs [][]byte) (n int, err error)
  • unix.Pwritev(fd int, iovs [][]byte, offset int64) (n int, err error)

I think https://go-review.googlesource.com/c/sys/+/548795 contains everything needed to implement this on Darwin.
In cases where the version is too old, the public functions in unix would simply return ENOSYS instead of running into a dyld error due to trying to jump to a function that doesn't exist.

@gopherbot gopherbot added this to the Proposal milestone Dec 14, 2023
@mschoenlaub mschoenlaub changed the title proposal: x/sys/unix: add support for iovec operations on darwin proposal: x/sys/unix: add support for vectrized IO syscalls on Darwin Dec 14, 2023
@mauri870
Copy link
Member

cc @golang/darwin

@gopherbot
Copy link

Change https://go.dev/cl/548795 mentions this issue: unix: support Readv, Preadv, Writev and Pwritev for darwin

@adonovan adonovan changed the title proposal: x/sys/unix: add support for vectrized IO syscalls on Darwin proposal: x/sys/unix: add support for vectorized ("scatter/gather") IO syscalls on Darwin Dec 22, 2023
@adonovan
Copy link
Member

adonovan commented Dec 22, 2023

Why just Darwin? p{read,write}v have been supported on Linux and various BSDs for a while. Ideally the sys interface would have implementations for all platforms that support it, even if the macOS implementation needs an additional compatibility check.

[Update: I now see that we have a Linux implementation already. But my point is that the proposal should cover the API change, and implementations for all platforms can follow at their own pace if they conform to the approved proposal.]

@mschoenlaub
Copy link
Author

Hm, yeah, @adonovan I think you are right. The goal should be to implement it on all platforms supported, but I agree on these implementations better coming in at their own pace.
However, I think I wasn't fully aware of actually proposing an API change of any sort, because due to the Linux implementation already being there, I just assumed that the API now basically has to be whatever the Linux implementation conforms to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Incoming
Development

No branches or pull requests

4 participants