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

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

Closed
brson opened this Issue Mar 27, 2012 · 9 comments

Comments

Projects
None yet
4 participants
@brson
Contributor

brson commented Mar 27, 2012

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

This comment has been minimized.

Show comment
Hide comment
@brson

brson Mar 27, 2012

Contributor

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.

Contributor

brson commented Mar 27, 2012

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.

@ghost ghost assigned brson Mar 28, 2012

@graydon

This comment has been minimized.

Show comment
Hide comment
@graydon

graydon Mar 28, 2012

Contributor

What a charming asymmetry. Full steam ahead!

Contributor

graydon commented Mar 28, 2012

What a charming asymmetry. Full steam ahead!

@jamorton

This comment has been minimized.

Show comment
Hide comment
@jamorton

jamorton Mar 29, 2012

Contributor

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?

Contributor

jamorton commented Mar 29, 2012

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

This comment has been minimized.

Show comment
Hide comment
@brson

brson Mar 29, 2012

Contributor

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

brson commented Mar 29, 2012

@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

This comment has been minimized.

Show comment
Hide comment
@brson

brson Mar 29, 2012

Contributor

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.

Contributor

brson commented Mar 29, 2012

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

This comment has been minimized.

Show comment
Hide comment
@brson

brson Mar 29, 2012

Contributor

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

Contributor

brson commented Mar 29, 2012

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

This comment has been minimized.

Show comment
Hide comment
@jamorton

jamorton Mar 29, 2012

Contributor

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

Contributor

jamorton commented Mar 29, 2012

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

This comment has been minimized.

Show comment
Hide comment
@fzzzy

fzzzy Mar 29, 2012

Contributor

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.

Contributor

fzzzy commented Mar 29, 2012

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

This comment has been minimized.

Show comment
Hide comment
@brson

brson Apr 21, 2012

Contributor

Implemented as a special scheduler.

Contributor

brson commented Apr 21, 2012

Implemented as a special scheduler.

@brson brson closed this Apr 21, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment