Discussion: "Timeouts and cancellation for humans"

You can use this thread to discuss the blog post Timeouts and cancellation for humans.

So requests doesn’t have to do anything to pass this through – when it eventually sends and receives data over the network, those primitive calls will automatically have the deadline applied.

Just to be clear – this refers to a hypothetical requests library with support for async and trio in particular (as implemented e.g. by asks), not the actual requests library, right? I tried running requests.get on a slow responding server inside a with trio.move_on_after(...) block, and trio's timeout was not applied.

Not complaining, just making sure I understand this correctly – if it worked without any effort required from third-party library developers, it would be downright magical :slight_smile:

As an aside, thank you so much for all your posts related to async, as well as the trio docs! Your writing is top-notch, you manage to keep it accessible yet technically detailed, a rare ability :slight_smile:

Never mind, I should have finished reading the article before starting to experiment and asking questions :slight_smile: The Summary section makes it pretty clear that requests indeed needs to be ported over to async + trio before the sample timeout code can work.

I’m guessing the timing on the Cancel tokens described here won’t be perfectly exact - it’ll take some (small) amount of time to call after, such that time.monotonic is slightly late.

Assuming that’s the case, would this timing error compound with repeated calls to after?
If not, why?, and if so, could the Cancel token structure be changed to fix this?

I’m guessing this isn’t super important for most of trio’s applications, but I was curious about it anyway - I’ve seen a similar construct in Ada where non-compounding timing errors matter a lot.

Trio lets you set timeouts as either relative or absolute times, and it always stores them internally as absolute times. For example, move_on_after(10) is just a convenient shorthand for move_on_at(trio.current_time() + 10), and sleep(10) is a shorthand for sleep_until(trio.current_time() + 10). So if you’re in a situation where you want to e.g. set a timer for every 10 seconds, you can do that by using the absolute time API: sleep_until(start_time + i*10).