main task needs to run on the main OS thread

[brson]

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.

[brson]

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.

[graydon]

What a charming asymmetry. Full steam ahead!

[jamorton]

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?

[brson]

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

[brson]

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.

[brson]

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

[jamorton]

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 =]

[fzzzy]

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.

[brson]

Implemented as a special scheduler.