On why await shouldn't be a method

language design
13

I don't think this quite holds either. Let me enumerate the reasons for which I believe a function might not return in current stable Rust:

  • The function panics:
    • panic=abort: the whole process aborts.
    • panic=unwind: the function exits via unwinding landing pads.
  • The execution thread is a daemon, and all non-daemon threads terminate.
  • The process aborts or is otherwise abruptly terminated.
  • The function returns !, thus it either:
    • loops forever,
    • panics, or
    • calls another function that returns !.
  • The OS has a bug and leaks your thread, or thread starvation via critical sections locks up OS resources.

And note also that any function call can not return by virtue of looping forever (halting problem). It doesn't matter what the types are, if any back edges exist in the function's control flow, it might loop forever, thus not returning.

A Future that is never resumed after the first poll has three reasons why that may be (and here I also give the Fn equivalent):

  • The awaited resource never becomes available (infinite blocking call),
  • The Future is Dropped (the call stack unwinds), or
  • The Future is leaked (this is a reactor bug; the closest synchronous analog would be thread starvation).

In async, the reactor becomes your "cooperative green thread" organizer rather than OS threads. Either one could have bugs, but looking at it semantically, I think it makes sense to ignore these.

1 Like