Proposal: add forkOnIO and friends to Control.Concurrent:

[Iavor Diatchki]

Hello,
Just a minor comment about the types:  it seems a lot more natural to
use Word instead of Int to identify CPUs and to report the number of
capabilities.  I can't think of any meaningful use of negative numbers
in these functions.
-Iavor



On Wed, Dec 22, 2010 at 8:08 AM, Simon Marlow <marlowsd at gmail.com> wrote:
> 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
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>