Description
There are some operations that are safe to call without a timeout set, like Event.wait when you know that another task will definitely call Event.set eventually. But for something like network IO, blocking without a timeout is basically always a bug.
In principle, this is pretty easy to check -- just make the dangerous operations call current_effective_deadline before running, and do something if the deadline is inf. (And most of these operations are already calling yield_if_cancelled, so in principle this check could be made almost free... though that interacts with #58).
The bigger question is how to expose this to users. Some options:
- Always check; make it an error to do network I/O without a timeout set.
- Always check; issue a warning if they're doing network I/O without a timeout set.
- Or combining these two approaches, issue a warning that has a default filter which makes it an error.
- Check when running in some sort of "debugging mode", like a special env-var set or an argument to
runor whatever.
I'm not a huge fan of "debugging mode" as an approach for something like this, just because this approach has reduced impact: lots of people who would benefit will probably not notice the feature exists and think to turn it on. OTOH maybe it's too obnoxious or creates too much of a slowdown to force people to have timeouts set, esp. for new users or things like test suites that use socketpairs? Further experimentation needed.