Stream: wg-async-foundations

Topic: global executors

boats (Nov 14 2019 at 17:23, on Zulip):

Wrote this post today:

Taylor Cramer (Nov 14 2019 at 18:29, on Zulip):

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

Taylor Cramer (Nov 14 2019 at 18:30, on Zulip):

Note, though, that this could be avoided by using thread-local spawners rather than a single global (but that has its own complexity costs)

boats (Nov 14 2019 at 18:31, on Zulip):

Yes. Well, its still possible using a different API from std::task::spawn of course

Taylor Cramer (Nov 14 2019 at 18:34, on Zulip):

@boats Not if the two libraries both set #[global_executor] internally, which is my fear

Taylor Cramer (Nov 14 2019 at 18:35, on Zulip):

but yes, that's a good point that we could potentially build best-practices that would help resolve that situation

Taylor Cramer (Nov 14 2019 at 18:36, on Zulip):

I can imagine making everyone declare #[global_executor] in every program would be rather unpopular, though

boats (Nov 14 2019 at 18:36, on Zulip):

I see what you mean. Yes, libraries shouldn't depend on crates that set global_executor either.

boats (Nov 14 2019 at 18:36, on Zulip):

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

Taylor Cramer (Nov 14 2019 at 18:37, on Zulip):

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 :)

boats (Nov 14 2019 at 18:38, on Zulip):

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.

Steven Fackler (Nov 14 2019 at 20:51, on Zulip):

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).

Steven Fackler (Nov 14 2019 at 21:00, on Zulip):

though it'll probably be much more common to set a global executor than global allocator

Taylor Cramer (Nov 15 2019 at 19:42, on Zulip):

much more common, I'd think

Khionu Sybiern (Nov 30 2019 at 20:36, on Zulip):

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?

nikomatsakis (Dec 03 2019 at 17:32, on Zulip):

@Khionu Sybiern :wave: -- not really, I think there's still a lot of active debate if that is something we would actually want

Khionu Sybiern (Dec 03 2019 at 21:44, on Zulip):

What are the issues being debated? Is there another place this discussion is happening?

nagisa (Dec 04 2019 at 21:20, on Zulip):

I’d much rather have some sort of a task-local mechanism and then make executor one of those task local things

Khionu Sybiern (Dec 04 2019 at 22:18, on Zulip):

Task-local? Not sure what you mean. The Executor can't belong to a Task.

Nemo157 (Dec 05 2019 at 08:22, on Zulip):

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

Nemo157 (Dec 05 2019 at 08:23, on Zulip):

There was significant discussion of the idea in this internals thread:

nagisa (Dec 05 2019 at 14:38, on Zulip):

What @Nemo157 said.

boats (Dec 10 2019 at 18:25, on Zulip):

@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.

boats (Dec 10 2019 at 18:25, on Zulip):

Happy to discuss these details with you if you'd be interested in writing an RFC for the API

Last update: Jul 02 2020 at 19:20UTC