Repository navigation
Tracking Issue for std::os::fd #98699
Description
Activity
Is "OS's that use fds" anything other than just "Unix and Wasi"? How close is Wasi to Unix? Would we treat Wasi similar to Unix in other situations too?
Is "OS's that use fds" anything other than just "Unix and Wasi"?
std::os::solid and std::os::fortanix_sgx also have similar types and traits. I'm not familiar with those platforms, but they also may want to use std::os::fd.
How close is Wasi to Unix? Would we treat Wasi similar to Unix in other situations too?
That's a complex question :-}. As a platform, WASI lacks some fundamental Unixy things, like
fork, signals, users, an ambient filesystem namespace, "/dev", and more. But as a layer on top of that, wasi-libc emulates some of these features, like an ambient filesystem namespace, in order to make it easier to port code to it. This is oversimplifying things, but in short, does Rust want to primarily target the compatibility abstractions, or the actual platform? We can obviously do some amount of both in practice, but forcfg(unix)in particular we do need to make a binary choice. There isn't an inherently correct answer here, but my sense is that overall it's better to treat WASI as something new, and to factor out Unix concepts like fds where it makes sense to share.Has there been any discussion on
impl std::io::Write for std::os::unix::io::OwnedFd?Has there been any discussion on
impl std::io::Write for std::os::unix::io::OwnedFd?I'm not aware of any. One way to do this today, if you're on Unix and know you're doing
write's, might be to usestd::fs::Fileinstead ofOwnedFd. Does that sound like a reasonable approach, or do you think it'd be valuable to have something else that can doWrite?I have an
OwnedFdto start with. This is more of a convenience that strictly necessary, but I also think it makes sense forOwnedFdto beWrite, rather than requiring it to be converted into aFilein order to do any IO.I can see the utility, but there is also the question of the overall API shape. Not all file descriptors support
write(2), though one might say the worst that happens is you getEBADForEINVAL, though if you say that's ok, then there's a question of what other operationsOwnedFdshould implement, and it's not clear where the boundary should be.There has also been some discussion about possible "view" types; I have a crate which lets you do
owned_fd.as_filelike_view<File>()providing a temporary&Fileview of anOwnedFdor similar. That part wasn't in the main I/O safety feature that was stabilized, though if something like that is useful in enough places, it could potentially be added in the future.Reacted by HugoI think
std::os::fdshould be available on more platforms than just wasm and Unix, e.g. Windows (and other POSIX OSes, which covers a lot more than just Unix) also have file descriptors.Since it's so commonly available, I propose just making it available everywhere and the rare OSes that don't support file descriptors in some fashion can just ignore it. this also provides the benefit of having a sneaky way to get a non-negative-one integer type:
#[repr(transparent)] struct NonNegOneInt(BorrowedFd<'static>)Reacted by Benjamin Saunders and HugoReacted by Alisa SirenevaReacted by 一年又一年On Windows, there are several different plausible choices to be the file descriptor type: C runtime library file descriptors, Foundation
HANDLEs, Winsock2SOCKETs, or something likeRawHandleOrSocket.Please don't use
BorrowedFd<'static>as an arbitraryNonNegOneInt.On Windows, there are several different plausible choices to be the file descriptor type: C runtime library file descriptors, Foundation
HANDLEs, Winsock2SOCKETs, or something likeRawHandleOrSocket.i would assume file descriptors always mean c runtime library file descriptors, since i've never seen handles or sockets referred to as file descriptors.
we could define FDs to be the type used for C's
closefunction, that way it should be more clear what's meant. these types could be moved tostd::ffito make that more clear since they are used primarily to interface with C (theopen/write/etc. functions)Reacted by HugoCould you describe what use case(s) would motivate this? I myself don't know of any use cases that want to use the C runtime library APIs on Windows.
Could you describe what use case(s) would motivate this? I myself don't know of any use cases that want to use the C runtime library APIs on Windows.
when C libraries use posix file descriptors and you want to use those libraries from rust
e.g.gzdopenwhich afaict is available on windowsMy feedback here is that if you're serious about wanting this, the more detail you can provide about use cases that would benefit from it, the easier it would be to consider.
One thing to keep in mind is that if
std::os::fdwere added on Windows and it used C runtime file descriptors, nothing instd, not evenFileitself, would be able to implementAsFd,AsRawFd,IntoOwnedFd,IntoRawFd, etc., because everything in std uses HANDLEs and SOCKETs.what I wanted to do was obtain a non-neg-one-int that would work on all platforms, the other reasons for wanting FDs are because I know it'll be useful on all POSIX OSes (including Windows), not because I have any plans to use it myself.
One thing to keep in mind is that if
std::os::fdwere added on Windows and it used C runtime file descriptors, nothing instd, not evenFileitself, would be able to implementAsFd,AsRawFd,IntoOwnedFd,IntoRawFd, etc., because everything in std uses HANDLEs and SOCKETs.that's not entirely true, file descriptors can be converted to handles and back:
_open_osfhandleand_get_osfhandleReacted by Bas SchoenmaeckersI stumbled upon the portability issue above today. I wrote
sd-listen-fdswith the intention that it gracefully no-op outside of Linux, allowing callers to use it in portable code withoutcfggates. This was motivated by the absence of any feature gate for thefdmodule visible in thestd::osdocs. I'll have to make my API significantly worse to work around this issue (e.g. returning ani32or a custom wrapper type).std::os::fd was stabilized in 1.66.0. Is there something else missing or should this be closed?
Yes,
std::os::fdis stabilized now, so this can be closed. Thanks!
Feature gate:
#![feature(os_fd)]This is a tracking issue for the
std::os::fdmodule, which is currently defined onboth Unix and WASI , and contains
OwnedFd,BorrowedFd,RawFd,AsFd,AsRawFd,IntoRawFd, andFromRawFd.Public API
The types and traits are the same as those already defined in
std::os::unix::ioand
std::os::wasi::io. This PR is just introducing a new alias for them to helpusers write portable code.
Steps / History
std::os::fdpublic. #98368Unresolved Questions
std::os. One can think of it as meaning "OS's that use fds". Is that weird?