Wrote this post today: https://boats.gitlab.io/blog/post/global-executors/
I bet you've already considered this already, but I wanted to make explicit that building this into std would make it impossible to have two (or more) global executors running in the same program, which, while undesirable, is possible today using the library-specific spawn functions
Note, though, that this could be avoided by using thread-local spawners rather than a single global (but that has its own complexity costs)
Yes. Well, its still possible using a different API from
std::task::spawn of course
@boats Not if the two libraries both set
#[global_executor] internally, which is my fear
but yes, that's a good point that we could potentially build best-practices that would help resolve that situation
I can imagine making everyone declare
#[global_executor] in every program would be rather unpopular, though
I see what you mean. Yes, libraries shouldn't depend on crates that set
That's one reason to provide a simple default, so libraries can "work" in testing mode without them having to add some
dev-dependency or something
These sorts of global "only one person gets to set it" resources are a nightmare in many other language's ecosystems-- I once spent multiple weeks untangling JVM logging frameworks from various OSS libraries :)
Agreed, which is why I think we should be very careful about how many we add, and I don't think we should make it possible for users to define their own.
The "only one global allocator" approach has worked out reasonably well so far IMO. Crates like jemallocator don't set the global allocator themselves by default. That's left to the end user (maybe by turning on a Cargo feature or something like that).
though it'll probably be much more common to set a global executor than global allocator
much more common, I'd think
Hi, I'd like to help out to get Global Executors going in Rust. Is there anything that's ready to be picked up, designing or code?
@Khionu Sybiern :wave: -- not really, I think there's still a lot of active debate if that is something we would actually want
What are the issues being debated? Is there another place this discussion is happening?
I’d much rather have some sort of a task-local mechanism and then make executor one of those task local things
Task-local? Not sure what you mean. The Executor can't belong to a Task.
The task normally only needs to have a handle to submit tasks to the executor, the executor itself can either be owned at a higher level or be reference counted via the handles
There was significant discussion of the idea in this internals thread: https://internals.rust-lang.org/t/global-executors/11295
What @Nemo157 said.
@Khionu Sybiern one thing that's more short-term is the
thread::block_on API, which is not such a huge addition as a global executor. There's an open PR, but I think it needs an RFC to work out some of the details.
Happy to discuss these details with you if you'd be interested in writing an RFC for the API