Proposal: add forkOnIO and friends to Control.Concurrent:

[Daniel Peebles]

Same with just about every other use of Int in the standard libraries and
even GHC.Prim :)

On Wed, Dec 22, 2010 at 5:03 PM, Iavor Diatchki <iavor.diatchki at gmail.com>wrote:

> 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
> >
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20101222/4e4d3521/attachment.htm>