Neal Alexander wrote:
Bulat Ziganshin wrote:
Hello Neal,
Monday, December 22, 2008, 11:07:32 PM, you wrote:
The threaded RT creates an OS thread for each CPU/core on the system and
uses them to multiplex userland threads. These are context switched
whenever they block/yield/gc and no priorities can be assigned.
not exactly. amount of OS threads created controlled by +RTS -N option
to the program; unless program has special function that RTS calls to
set up this value
they are switched on every minor GC which by default occurs after
each 256kb allocated which is rather frequent event
It seems like we could get some priority based scheduling (and still be
slackers) if we allow marked green threads to be strictly associated
with a specific OS thread (forkChildIO?).
forkOS creates new haskell thread and new OS thread specially for it
The docs say that the forkOS thread is still scheduled by the Haskell RT
though. What would happen if you bump its priority through FFI?
Probably not much, unless you had specified a larger -N value than the
number of cores in your machine, in which case the OS threads are being
multiplexed by the OS onto the available cores. In that case the relative
priorities of the OS threads would affect the scheduling decisions made by
the OS.
What about this scenario:
forkOS = OS thread A1, Haskell Thread A2
forkIO = Haskell thread B
Could thread B potentially be run on thread A1?
No.
Would the RT yield
thread A2 to give time to another Haskell thread?
Sure, A2 behaves like any other Haskell thread.
Cheers,
Simon
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
