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
We have PipeReceiveStream and PipeSendStream classes on Unix, that are currently not exposed publicly; they're only used internally for subprocesses.
The actual code is a pretty generic building block: they can wrap around any Unix file-descriptor that supports non-blocking mode. So they could potentially be useful for talking to FIFOs, TTYs, stdio streams (#174), etc.
Should we expose them more directly? If so, how? In trio.hazmat, with some sort of os.fdopen equivalent?
If we do we'll want to think through the ownership semantics: should they take ownership of a passed in fd, or should they dup it?
Also, they should restore the fd's blocking/non-blocking state before closing it.
The text was updated successfully, but these errors were encountered:
We have
PipeReceiveStream
andPipeSendStream
classes on Unix, that are currently not exposed publicly; they're only used internally for subprocesses.The actual code is a pretty generic building block: they can wrap around any Unix file-descriptor that supports non-blocking mode. So they could potentially be useful for talking to FIFOs, TTYs, stdio streams (#174), etc.
Should we expose them more directly? If so, how? In
trio.hazmat
, with some sort ofos.fdopen
equivalent?If we do we'll want to think through the ownership semantics: should they take ownership of a passed in fd, or should they dup it?
Also, they should restore the fd's blocking/non-blocking state before closing it.
The text was updated successfully, but these errors were encountered: