main task needs to run on the main OS thread

In some operating systems (mac, win) the main thread is special and can do special things (on mac you have to be on the main thread to do cocoa API calls). Somehow we probably need to arrange for the main task to run on the main thread, which is a pain.

Here's the current plan. The main task continues to be non-special, but we create another single-threaded scheduler called 'main_thread_sched' that has a single scheduler thread running on the OS main thread. Users can choose to spawn tasks into this scheduler.

Requires giving schedulers a first class representation in core, reworking how scheduler lifetime works, and refactoring a bunch of runtime code.

What a charming asymmetry. Full steam ahead!

Is that bit of flexibility worth such a convoluted solution? What's wrong with the user limiting their calls to those few libraries (like cocoa) to the main task?

@Jonanin that's a point worth considering. My concern previously was that making the main task special could have some subtle, non-obvious side effects.

Off hand this is what I can think of:

The main task will be pinned to a single thread so could ocassionally get scheduled unfairly if there are bad neighbors on the same thread (assuming we have work stealing).
I believe there will need to be some extra work done by the runtime on the main OS thread between scheduler loops, though I'm not entirely sure yet.
In the case of an application that is actually using the OS event loop, one of the scheduler threads on the default scheduler is going to have a bunch of external work contending for time, and not performing the same as the other threads. For example, the runtime might be embedded in another application, with the main scheduler being driven from 'outside' by the OS's event loop, and between each turn of the scheduler loop you have to stop to dispatch OS messages. This would affect not just the performance of the main task, but any task that randomly gets scheduled onto that thread.

Of course, to combat that last point we could have the main task in it's own single-threaded scheduler and configured to spawn new tasks into a second scheduler that is more fair.

That in itself (the main thread spawning into a different scheduler) is some subtle behavior though that I'm not sure the implications of.

Not that it counts, since I don't know the full implications or full architecture of the system, but I vote for putting the main task in its own thread =]

brson, the initial design sounds right. There are too many downsides to having the main task always on the main thread. Better to have each consumer of an os API have to request to be on the main thread if it needs to be.

Implemented as a special scheduler.

Store failure reason into assess metadata (rust-lang#2166)

fixed the typo (rust-lang#2058)

Merge pull request rust-lang#2058 from RalfJung/s390x-minmax

Merge rust-lang#2058

Auto merge of rust-lang#2058 - RalfJung:variadic, r=RalfJung

Navigation Menu

Repository navigation

main task needs to run on the main OS thread #2058

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

main task needs to run on the main OS thread #2058

Description

Activity

brson commented on Mar 27, 2012

graydon commented on Mar 28, 2012

jamorton commented on Mar 29, 2012

brson commented on Mar 29, 2012

brson commented on Mar 29, 2012

brson commented on Mar 29, 2012

jamorton commented on Mar 29, 2012

fzzzy commented on Mar 29, 2012

brson commented on Apr 21, 2012

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions