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

[njsmith]

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.

[Zac-HD]

I'd make it an error to do network IO without a timeout, but provide two escape hatches: a context manager to locally disable the check, and (maybe) an argument to trio.run to globally disable it.

The idea is that the defaults are safe, but it's also possible to carve out small and easily-greppable dangerous areas - or just move fast and hang forever if that's what you really want.

TBH I'm not entirely convinced that the argument-to-trio.run form of escape hatch is a good idea - it wouldn't be too hard to use the context manager at the root of a task tree, just inside the main function, and that would let us clearly mark it out as hazardous.