feat: introduce try_executor to detect whether in scope of smol

[kezhuw]

This way third parties can decide how to spawn in runtime time but not coding time.

It is similar to tokio::runtime::Handle::try_current.

Background

I created spawns to propose thread context task spawner. It has compatibility code to spawn through smol, but can't coexist with async-global-executor, since they both has no thread context info like tokio::runtime::Handle::try_current.

With this spawns or other third parties are capable to detect whether codes are running in scope of smol, and make the decision about which executor to spawn into.

[notgull]

Generally the builtin executor for smol is meant for small testing cases only. I'm hesitant to add more infrastructure to it. Frankly the best way of handling executors in smol is to pass the executor to whatever you're calling.

[kezhuw]

Thank you for reviewing!

Generally the builtin executor for smol is meant for small testing cases only.

Yeh, I saw this in the rust docs 😮‍💨 . My thought is that people will use it anyway as it is the context-less entry point despite how the doc states.

Frankly the best way of handling executors in smol is to pass the executor to whatever you're calling.

This is what spawns try to solve. Let the binary decides executor, but not library.

smol has the entry point for binary, so I am here. If a library is using spawns, the migration from the builtin executor to customized executor should be easy in binary.

• spawns currently supports smol through feature "smol".
• The customized executor enter() spawn scope for all executor threads.

Though spawns supports smol's builtin executor currently. But it can't coexist with other global executor. It still would be nice if smol could provides api for library to question "do we run in scope of smol's builtin executor or not ?". This way library could still spawn task in runtime agnostic way even there are multiple global executors.

I'm hesitant to add more infrastructure to it.

That is fine, though I think it is actually pretty small (two interceptions and one new api). Thank you anyway !

[kezhuw]

Hmm, I think there is no strong reason for spawns to panic on multiple blindly global spawners. See kezhuw/spawns#1.

Feel free to close this if there is no intention to expose "do we run in scope of smol's builtin executor or not ?" to third parties. I think executable could specify one though env variable or alike in case of global executors.

Thanks anyway!

[notgull]

Feel free to close this if there is no intention to expose "do we run in scope of smol's builtin executor or not ?" to third parties. I think executable could specify one though env variable or alike in case of global executors.

ACK