Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: introduce try_executor to detect whether in scope of smol #307

Closed
wants to merge 1 commit into from

Conversation

kezhuw
Copy link

@kezhuw kezhuw commented May 6, 2024

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.

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`.
@notgull
Copy link
Member

notgull commented May 6, 2024

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
Copy link
Author

kezhuw commented May 6, 2024

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
Copy link
Author

kezhuw commented May 6, 2024

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
Copy link
Member

notgull commented May 7, 2024

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

@notgull notgull closed this May 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants