Proposal: add forkOnIO and friends to Control.Concurrent:

[Simon Marlow]

On 22/12/2010 15:55, Duncan Coutts wrote:
> On 22 December 2010 11:41, Simon Marlow<marlowsd at gmail.com>  wrote:
>> Ticket:
>>
>>   http://hackage.haskell.org/trac/ghc/ticket/4859
>>
>> I think these functions are implementation-independent enough to add to the
>> main `Control.Concurrent` API:
>>
>> {{{
>> {- |
>> Like 'forkIO', but lets you specify on which CPU the thread is
>> created.  Unlike a `forkIO` thread, a thread created by `forkOnIO`
>> will stay on the same CPU for its entire lifetime (`forkIO` threads
>> can migrate between CPUs according to the scheduling policy).
>> `forkOnIO` is useful for overriding the scheduling policy when you
>> know in advance how best to distribute the threads.
>>
>> The `Int` argument specifies the CPU number; it is interpreted modulo
>> the value returned by 'getNumCapabilities'.
>
> While Int is clearly enough for a multi-processors single node system,
> I wonder if there is something slightly more general that would give
> us a common API with the Eden / distributed Haskell people. For
> example in MPI the identification of a node is rather more complex
> than a single integer. Perhaps some more abstract identifier for a
> capability would be useful. Closely related of course is how one
> discovers the available capabilities.

There aren't any systems that support remote forkIO, and it's not clear 
that forkIO is the right abstraction for a distributed system.  See for 
example the design at

   http://hackage.haskell.org/trac/ghc/wiki/ErlangInHaskell

which uses a different primitive for remote forks.

I think we can safely consider forkIO (and forkOnIO) to be node-local 
forks, so we don't have to worry about a more complex node structure here.

Cheers,
	Simon