Same with just about every other use of Int in the standard libraries and even GHC.Prim :)<br><br><div class="gmail_quote">On Wed, Dec 22, 2010 at 5:03 PM, Iavor Diatchki <span dir="ltr"><<a href="mailto:iavor.diatchki@gmail.com">iavor.diatchki@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hello,<br>
Just a minor comment about the types: it seems a lot more natural to<br>
use Word instead of Int to identify CPUs and to report the number of<br>
capabilities. I can't think of any meaningful use of negative numbers<br>
in these functions.<br>
<font color="#888888">-Iavor<br>
</font><div><div></div><div class="h5"><br>
<br>
<br>
On Wed, Dec 22, 2010 at 8:08 AM, Simon Marlow <<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>> wrote:<br>
> On 22/12/2010 15:55, Duncan Coutts wrote:<br>
>><br>
>> On 22 December 2010 11:41, Simon Marlow<<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>> wrote:<br>
>>><br>
>>> Ticket:<br>
>>><br>
>>> <a href="http://hackage.haskell.org/trac/ghc/ticket/4859" target="_blank">http://hackage.haskell.org/trac/ghc/ticket/4859</a><br>
>>><br>
>>> I think these functions are implementation-independent enough to add to<br>
>>> the<br>
>>> main `Control.Concurrent` API:<br>
>>><br>
>>> {{{<br>
>>> {- |<br>
>>> Like 'forkIO', but lets you specify on which CPU the thread is<br>
>>> created. Unlike a `forkIO` thread, a thread created by `forkOnIO`<br>
>>> will stay on the same CPU for its entire lifetime (`forkIO` threads<br>
>>> can migrate between CPUs according to the scheduling policy).<br>
>>> `forkOnIO` is useful for overriding the scheduling policy when you<br>
>>> know in advance how best to distribute the threads.<br>
>>><br>
>>> The `Int` argument specifies the CPU number; it is interpreted modulo<br>
>>> the value returned by 'getNumCapabilities'.<br>
>><br>
>> While Int is clearly enough for a multi-processors single node system,<br>
>> I wonder if there is something slightly more general that would give<br>
>> us a common API with the Eden / distributed Haskell people. For<br>
>> example in MPI the identification of a node is rather more complex<br>
>> than a single integer. Perhaps some more abstract identifier for a<br>
>> capability would be useful. Closely related of course is how one<br>
>> discovers the available capabilities.<br>
><br>
> There aren't any systems that support remote forkIO, and it's not clear that<br>
> forkIO is the right abstraction for a distributed system. See for example<br>
> the design at<br>
><br>
> <a href="http://hackage.haskell.org/trac/ghc/wiki/ErlangInHaskell" target="_blank">http://hackage.haskell.org/trac/ghc/wiki/ErlangInHaskell</a><br>
><br>
> which uses a different primitive for remote forks.<br>
><br>
> I think we can safely consider forkIO (and forkOnIO) to be node-local forks,<br>
> so we don't have to worry about a more complex node structure here.<br>
><br>
> Cheers,<br>
> Simon<br>
><br>
> _______________________________________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
><br>
<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br>