Proposal: add forkOnIO and friends to Control.Concurrent:

Iavor Diatchki iavor.diatchki at
Wed Dec 22 23:03:50 CET 2010

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.

On Wed, Dec 22, 2010 at 8:08 AM, Simon Marlow <marlowsd at> wrote:
> On 22/12/2010 15:55, Duncan Coutts wrote:
>> On 22 December 2010 11:41, Simon Marlow<marlowsd at>  wrote:
>>> Ticket:
>>> 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
> 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

More information about the Libraries mailing list