You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@aturon and I have long had the desire to audit all of our various std::{io, process, env, fs, os} APIs with what they're actually doing on all platforms. This is very helpful for getting more information about the precise semantics of the API in various corner cases as well as explaining what's going on under the hood.
This is a pretty big bug and probably shouldn't be tackled all at once, but what we've been thinking is something along the lines of:
All of these APIs will have a "Platform Behavior" section of the documentation.
Each API will document what syscall it invokes, as well as perhaps how the various arguments translate. For example OpenOptions::open is documented on unix as calling the open syscall followed by a ioctl to set the file descriptor to CLOEXEC. The documentation would also state that we may one day use newer versions of open which allow setting CLOEXEC atomically.
We want to be relatively relaxed in the documentation to allow ourselves room to tweak various aspects here and there in the future.
Ideally this is will happen exhaustively to all I/O APIs, but that's probably a long ways out. Either way seems like a good bug to track!
The text was updated successfully, but these errors were encountered:
@aturon and I have long had the desire to audit all of our various
std::{io, process, env, fs, os}
APIs with what they're actually doing on all platforms. This is very helpful for getting more information about the precise semantics of the API in various corner cases as well as explaining what's going on under the hood.This is a pretty big bug and probably shouldn't be tackled all at once, but what we've been thinking is something along the lines of:
OpenOptions::open
is documented on unix as calling theopen
syscall followed by aioctl
to set the file descriptor to CLOEXEC. The documentation would also state that we may one day use newer versions ofopen
which allow setting CLOEXEC atomically.Ideally this is will happen exhaustively to all I/O APIs, but that's probably a long ways out. Either way seems like a good bug to track!
The text was updated successfully, but these errors were encountered: