[Haskell-cafe] Re: ANN: priority-sync-0.1.0.1: Cooperative task prioritization.

[Christopher Lane Hinson]

> 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