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

Should we somehow expose Pipe*Stream on Unix, and if so, how? #829

Closed
njsmith opened this issue Dec 28, 2018 · 0 comments · Fixed by #1129
Closed

Should we somehow expose Pipe*Stream on Unix, and if so, how? #829

njsmith opened this issue Dec 28, 2018 · 0 comments · Fixed by #1129

Comments

@njsmith
Copy link
Member

njsmith commented Dec 28, 2018

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.

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

Successfully merging a pull request may close this issue.

2 participants