smol-rs
Avoid spawning the async-io thread if possible
In most programs that use async-io, the user will simply run block_on at the top level. However, this will still spawn the async-io thread despite it not being necessary. Would it be possible to avoid that?
I don't know, this feels like it would be an easy footgun to accidentally set off. See the issues with #59
Yeah, both of the currently submitted PRs seem to cause problems with the existing code when the threads are disabled.
@taiki-e Do you mind if I close this as well as #59? At worst, all the async-io thread will do is idle on the reactor lock and occasionally pick up slack. Even in those cases, it can prevent programs from grinding to a halt. The only reason I can think of to plan this is if we wanted to port smol to no_std for some reason.
Yeah, theoretically it would be more efficient to have no threads, but I don't see this as some kind of bug or problem that needs to be fixed in the near future.
For the single thread use case, we can get around the pre-emption deadlock by having the block_on call just refuse to give up the reactor lock if it sees that BLOCK_ON_COUNT is equal to 1. Then we only spawn the reactor thread once BLOCK_ON_COUNT is bumped to 2 or if an asynchronous resource is used with no block on threads.
For the multi threaded use cases, this definitely requires more thought and synchronization. Possibly so much synchronization that it stops being worth it. This requires more thought and benchmarking... especially since the current reactor is especially stable and I don't want to rock that boat too hard.
I'd accept a PR for the single threaded use case.