Thanks, Nathaniel. Very instructive, thought-provoking write-up!
One thing occurred to me around the time of reading this passage:
> "Once the cancel token is triggered, then all future operations on that token
> are cancelled, so the call to ws.close doesn't get stuck. It's a less
> error-prone paradigm. ... If you follow the path we did in this blog post,
> and start by thinking about applying a timeout to a complex operation
> composed out of multiple blocking calls, then it's obvious that if the first
> call uses up the whole timeout budget, then any future calls should fail
> immediately."
One case that's not clear how should be addressed is the following.
It's something I've wrestled with in the context of asyncio, and it
doesn't seem to be raised as a possibility in your write-up.
Say you have a complex operation that you want to be able to timeout
or cancel, but the process of cleanup / cancelling might also require
a certain amount of time that you'd want to allow time for (likely a
smaller time in normal circumstances). Then it seems like you'd want
to be able to allocate a separate timeout for the clean-up portion
(independent of the timeout allotted for the original operation).
It's not clear to me how this case would best be handled with the
primitives you described. In your text above ("then any future calls
should fail immediately"), without any changes, it seems there
wouldn't be "time" for any clean-up to complete.
With asyncio, one way to handle this is to await on a task with a
smaller timeout after calling task.cancel(). That lets you assign a
different timeout to waiting for cancellation to complete.
--Chris
On Thu, Jan 11, 2018 at 2:09 AM, Nathaniel Smith <n...@pobox.com> wrote:
> Hi all,
>
> Folks here might be interested in this new blog post:
>
> https://vorpus.org/blog/timeouts-and-cancellation-for-humans/
>
> It's a detailed discussion of pitfalls and design-tradeoffs in APIs
> for timeout and cancellation, and has a proposal for handling them in
> a more Pythonic way. Any feedback welcome!
>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org
> _______________________________________________
> Async-sig mailing list
> Async-sig@python.org
> https://mail.python.org/mailman/listinfo/async-sig
> Code of Conduct: https://www.python.org/psf/codeofconduct/
_______________________________________________
Async-sig mailing list
Async-sig@python.org
https://mail.python.org/mailman/listinfo/async-sig
Code of Conduct: https://www.python.org/psf/codeofconduct/
