Let `await` hang the isolate + observatory support.

[lrhn]

Currently the VM stops an isolate when there are no queued events, scheduled timers or open receive ports. That means that code like:

main() async {
   await foo();
   print("DONE");
}

may terminate at the await if the foo code returns a future with nobody scheduled to complete it. That can happen through any number of bugs, but it is hard to debug when the VM just terminates. The code looks like direct-style code, and the user expects it to either stop at the await or continue after it - but not to exit in the middle.

Similarly it may fail to run finally blocks:

main() async {
  try {
     await foo();
  } finally {
     print("DONE");
  }
}

This can also terminate at the await, which is even less expected. It's not absolutely wrong because the code does't actually skip the finally, it just kills the isolate before it gets there.

In any case, it's unexpected behavior and hard to debug.

How about letting all pending await calls be registered by the isolate, and visible using the observatory, and not terminate the isolate while an await is waiting. That would change the behavior from early termination to look like a deadlock (which it most likely is). The user can then use the observatory to see in which places in async functions the isolate is currently waiting which will aid debugging - it's easy to see why "DONE" is not being printed if the await on the previous line is blocked.

[sethladd]

cc @johnmccutchan

[johnmccutchan]

@rmacnak-google

[turnidge]

This bug is a two part bug. One part is an Observatory feature request, the other is a kind of await feature request asking for different vm termination conditions. I'm adding @mhausner to the bug to comment on the latter.

[mhausner]

I think Lasse has a good point here. I'll look into this.

It wasn't clear to me immediately how you create a Future that isn't scheduled for completion, but for the record:

main() async {
  await new Completer().future;
  print("DONE");
}

[mhausner]

On second thought, is "hanging" the isolate the right thing to do? And why only for futures that are being awaited? Why not all uncompleted futures, or even uncompleted futures that may have been garbage collected because nobody has a reference to them anymore?

Ignoring the Observatory feature wish, would it be a good enough approximation to make sure the future returned by main() completes?

[lrhn]

The reason for making this only apply to "await" expressions is that they look like straight-line code, and users will expect straight-line code behavior from it. It doesn't look like code that is split into separate chunks that will each eventually (maybe) be called from the event loop, so actually behaving like that is surprising - function terminates in the middle without any errors being printed - nothing suggests that foo(f) async {print("before");await f;print("after");} should be able to print "before", but neither print "after" nor throw - there is no control flow point in the middle that allows it to suddently exit (and omit finally blocks on top of that).

This is proposing that async/await code should act like it is a normal function call being blocked at the await. Until that function call terminates, the program isn't "done", it's just stuck. That's what the code was made to look like, and I think its behavior should follow that.

For an end user, the difference will be between hanging and terminating silently. The former is easier to both explain and debug. I don't see a third option - making one of the blocked awaits throw instead is not safe (it might be taken as the future completing with an error, which could mean something else), and it might trigger code that expects to only run after some other (also blocked) code has run.

Futures that are just used "normally" (without await) are much more obviously asynchronous and using the event loop, and it's less surprising if they never get completed. Also, there are probably quite a lot of futures that are never completed. If nobody waits on them, that's not a problem. It only becomes a problem with await because someone, inside (what looks like) a running function call, is stuck waiting for that future.

It's not necessarily enough to check that a future returned by main completes - for one thing, there might not be one, you could call an async function from a sync main and ignore the result.