-
-
Notifications
You must be signed in to change notification settings - Fork 346
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
Design: higher-level stream abstractions #8
Comments
The SSL branch (#107) has a set of ABCs for streams that I'm pretty happy with. One place that I realized it's lacking, though, while trying to write tests for SSL-over-streams, is in specifying exception handling. In particular, there are some pretty generic things that can happen to streams:
(Notes: The last two cases are due to python sockets setting their internal fileno to -1 when closing. In the second case, the WinError 10053 is WSAECONNABORTED.) There's also ECONNRESET / And SSL wrappers add their own exciting ways of wanting to report these same failure modes. I'm guessing when we get to subprocesses then pipes/named pipes will have their own weirdness. So there's at the very least a temptation to collapse these down into:
And of course we'd use exception chaining to preserve the original cause as well, so at least for debugging the information is there. The question is whether this would be making it hard to reliably/programmatically access information that turns out to be important, like if for some reason an application calling TCP distinguishes between FIN and RST as ways of ending a connection. IIUC the difference is that FIN is a regular "eof" packet (e.g. sent by Maybe the thing to do is to allow |
Ugh, here's a problem with the above: so far I've been trying to keep the And I think it'd even be reasonable to say that our sockets convert OSErrors into the special trio exceptions in some cases. But... sometimes sockets aren't streams at all. It'd be really weird to raise Ideas:
...I guess if we go with the "SocketStream" approach (the 2nd option above) then it might also make sense to move our other weirdness there, like the "improved" default socket options (see #72). |
I guess we should probably also add (If we're breaking from the socket API, should we also rename the methods to |
#107 is merged with a decent |
There's a gesture towards moving beyond concrete objects like sockets and pipes in the
trio._streams
interfaces. I'm not sure how much of this belongs in trio proper (as opposed to a library on top), but I think even a simple bit of convention might go a long way. What should this look like?Prior art: Twisted endpoints. I like the flexibility and power. I'm not as big a fan of the strings and plugin architecture, but hey.
The text was updated successfully, but these errors were encountered: