How can we help catch the mistake of issuing a blocking operation without a timeout set?

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 run or 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.

Start by reading the existing network I/O operations that call current_effective_deadline and yield_if_cancelled, and review the interaction with #58. Compare the proposed always-error, warning, and debugging-mode approaches, including behavior for socketpairs and possible slowdown. Done means selecting and implementing a clear policy, with experiments or tests covering blocking operations without a timeout.