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