-
-
Notifications
You must be signed in to change notification settings - Fork 338
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
Cancelling a fail_after
results in TooSlowError, even though the timeout didn't expire
#698
Comments
On 28.09.2018 18:28, Jörn Heissler wrote:
|TooSlowError| is especially strange because the timeout wasn't reached.
The problem is that `fail_after` cannot discover that it was cancelled
manually by yourself instead of the timeout.
Fix: create a secondary scope inside the `fail_after`, and cancel that.
…--
-- Matthias Urlichs
|
Thanks! |
Likely no one has ever thought to manually cancel a fail_after(). Would you describe your use case? Behavior seems completely in line with docs, though I understand not what you're wanting:
There are two things that can be cancelled: 1) the cancel scope, 2) the notion that an exception should be raised. The cancel() method can only be bound to one, and since it's a method on the CancelScope object it understandably is the former. Possibly need a |
Once we head down this road, I think it should be possible to dynamically transition between plain cancel scope, move_on_after, and fail_after semantics while the cancel scope is in flight. It's already possible to do that with the first two via |
In a nutshell: There's a long running task (might run infinitely). When a certain event happens, I want to finish it without error, so I'd cancel it. If the event does not occur within N seconds, I want the task to abort with an error. That task receives messages from a stream and runs a callback for each message. The callback might then cancel the task. My code and design are flawed and I'm going to rewrite it without using callbacks. Then the above use case won't exist anymore. I once learned that I need to use state machines and callbacks, unlearning this is hard.
I must have missed this. So it looks like the behaviour does match the docs. Still I find it strange that cancelling one |
Huh, interesting case. So in general, trio doesn't track the reason why a scope was cancelled – a timeout is exactly the same as calling And But yeah the end result is kind of surprising here! Some options:
|
Hmm, above message was written this morning and then I forgot to hit post, so the discussion has overtaken it a bit. I have trouble telling how useful If you're rewriting your code anyway, then maybe we should leave this be for the moment, and just keep this thread in mind in case it comes up again in the future? |
fail_after
results in Cancelled
exceptionfail_after
results in TooSlowError, even though the timeout didn't expire
My use case (close enough): I'm connecting to a host and my connection-setup handshake is protected by a So, yes, I'm all for some way to fix this issue, preferably one that doesn't require two additional syscalls to |
AFAICT, this issue only applies to cancelling the Are you seeing that cancelling a scope that encloses the |
Yes, that's what I'm seeing. I don't have a test case (a trivial attempt to reproduce this failed) but in my code the |
Are you using a released Trio, or master? There were some recent cancellation changes that could theoretically have bugs... I'm not able to reproduce the outer-cancellation-causes-inner-TooSlowError on master with a simple case either, though. |
I've got some code that uses
fail_after
and cancels itself, example below.My assumption was that the context manager just exits without any error. Yet it raises a
Cancelled
andTooSlowError
.When I don't use
fail_after
butopen_cancel_scope
, things work as expected. I can't find anything in the docs that explain the difference. And I can't think of any good reason either.TooSlowError
is especially strange because the timeout wasn't reached.Version: ce131cd on cpython3.6.6
Result is:
The text was updated successfully, but these errors were encountered: