Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
When you run the following program:
You get this error
Because there is literally nothing on the event loop which means that there is nothing that could ever resolve the promise, and yet we should still be suspended. Actually, there is some state in that
main()
registersSIGINT
handlers, but both Deno and Node say thatSIGINT
doesn't "count" because the pre-structured-concurrency state of the art is to call process.exit() on interrupt and shoot the process in the heart. Effection on the other hand removes the sigint handler, so if that "counted" themain()
would hold the process open, but release it after the signal handlers had run.Approach
This just holds the process open by installing a
setInterval
that fires every 2^30 milliseconds (about ten years). It is removed when main is finished.Possible Drawbacks or Risks
One thing that has occured to me which I'm not sure about is that
run()
will still exhibit the same behavior. In other words:Will complain that the
run()
promise has not resolved, but that the event loop is exhausted. That feels a bit asymmetric and suprising which is not great. We could makesuspend()
itself hold the event loop with the long interval, although that worries me that every singlesuspend()
operation would install a dummy interval. Is it a tough look to have hundreds, or perhaps even thousands of dummy intervals?Alternate Designs
Another option would be to make any Frame that does not have a parent (aka root frame) of which there is generally only one, hold the event loop, until its destruction. That would allow it to work with a bare
run()
, but not install asetTimeout
every time a suspend() operation is encountered. The number of dummy intervals would be equal to the number of root frames (most of the time one).Learning
setInterval()
https://stackoverflow.com/questions/34350928/setinterval-with-infinity/34351063#34351063