Yeah that's still not the way the code reads. The closer the code behaves to the way it reads the better in my book.

How does it read to you?

I'm assuming the loop would terminate with an exception... like `await events.pointermove` would raise some cancellation exception that would be silently captured.

Sounds like the Abro runtime never resumes the tasks so how could they throw?

These 3 functions will stop on `await event.xxx` (if not, they will continue to execute or terminate). So when one of the functions is terminate https://github.com/pdubroy/handling-user-input/blob/main/abr...

   await Promise.any(fibers.map((f) => f.run()));
   fibers.forEach((f) => f.terminate());

Abro will reject the promise of these `await event.xxx` https://github.com/pdubroy/handling-user-input/blob/main/abr...

    this._promises.forEach(({ reject }) => reject());

Which will throw an Exception and exit the 2 other functions.

Oh... on second thought I realize the exception would have to come from `event.pointermove` (for example), and that object doesn't know anything about the receiver or whether it should cancel. So yeah, this does seem problematic.

Are you worried about when the case when an exception should be thrown from the thing being awaited? I'm not familiar with Arbo but usually the promise holds on to the exception until its observed. It could be that Arbo is configured to ignore the exception if the task is already cancelled.

Wouldn't that result in a thread leak? (Or a "fiber" leak)

If a task has yielded its not holding on to a thread. A loop that wasn't yielding would leak, though.