Re: Proposal: add forkOnIO and friends to Control.Concurrent:

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 wrote:

On 22/12/2010 15:55, Duncan Coutts wrote:

...

On 22 December 2010 11:41, Simon Marlow  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@haskell.org http://www.haskell.org/mailman/listinfo/libraries