-
Notifications
You must be signed in to change notification settings - Fork 241
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
_read_wait and friends are documented as being exported from top-level curio package, but they aren't #46
Comments
Good catch. The low-level traps are not exported as part of the API normally. I'll fix the docs to make sure that's more clear. I'm actually kind of curious about the timeout comment though. I've been refactoring virtually all of the timeout handling into a different approach (in the "wip" branch). Were you tracking down a bug in timeout handling or just looking to see how it worked? |
In the first instance I was just looking to figure out how the API worked :-).
But, this sounds like it could be relevant to my interests... Notes towards a Curio HTTP server, including some comments on missing timeout-related features: https://github.com/njsmith/h11/blob/master/curiosittp.py (Context: https://github.com/njsmith/h11/blob/master/README.rst) |
Oh. Interesting. I've actually been bothered a lot by timeout handling in the first version. Partly it's the fact that every single blocking operation can timeout. If I put a timeout option on everything, it makes the API unnecessarily complicated. Also, there's the problem of a cumulative timeout as your describe. In the current "work in progress" curio, I've taken away the individual timeout features and replaced them with a new call that can work on a single operation like this:
Alternatively, you can apply it to a whole block of statements as a context manager
This latter form is basically the same as the timeout() manager you have in your code (although implemented as part of the kernel itself). I've used the name "timeout_after" to maybe make it more clear that the timeout is a cumulative timeout as opposed to a per-operation timeout. |
I guess if we just invented the same construct then that's a good sign :-). I haven't written enough curio code to identify which things are particularly annoying, but it is true that the need for a "cumulative timeout" was one of the first things I barked my shin on -- I wanted to add a (Terminology nitpicking/brainstorming: I was thinking about the word "deadline" as a possibly useful piece of terminology, emphasizing that the final time is fixed rather than being relative to each operation like a timeout. "Cumulative timeout" makes sense too, though I had to roll it around for a bit in my head before I could really process it. Or what do you think of |
Original issue on documentation fixed. |
This page says:
But:
It seems to be only in
curio.kernel._read_wait
. I suppose this is a better place for it and the bug is just in the docs, but either way fyi :-)(Found because I was trying to track down what happens if a timeout expires; it doesn't seem to be mentioned in the reference manual.)
The text was updated successfully, but these errors were encountered: