Is 'claim' the only way to execute tasks?
Lets say you create a task pool for 1 hardware thread.
pool <- newTaskPool fast_queue_configuration 1 ()
If a task blocks/sleeps while holding a claim, none of the other tasks can
run right?
Correct, but you can wrap the blocking call inside
claim Release {- . . . -}
to release the claim temporarilty.
Is it possible to create a task pool for 2 hardware threads having one task
dominate 1 CPU (render thread), and have other tasks multiplex IO on the
other CPU __without stalling each other when blocked__? What happens if you
release the room claim before blocking in IO? Does the thread schedule on a
random CPU?
priority-sync only controls access to abstract Rooms that, in the
motivating example, represent the resource limitation of the number of
hardware threads.
Tasks run inside their calling thread, on a CPU dictated by the RTS, so
just use forkOnIO to create a thread that is locked to a specific
capability if that's really what you want. priority-sync won't be aware
that you're doing this.
In your case, you may want to allow the rendering thread to run outside of
the task pool, and create a room of size (max 1 $ numCapabilities-1) for
all of the worker threads. Then wrap all relevant blocking calls as
described above (if this is prohibitively combersome, please advise me).
Another possibility, if the rendering thread is from something like a GLUT
callback, is to have the rendering thread claim the Room using the
Unconstrained context. Then you will likely end up with more threads
claiming the room than the size of the Room, but the rendering
thread will never be made to wait, and the Room will continue to block the
worker threads until it has returned to within it's configured
constraints.
Friendly,
--Lane
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
