[plt-dev] Parallel Futures Release

Yes, this is definitely on our list.

-James

On Sun, Dec 13, 2009 at 11:58 AM, YC <yinso.chen at gmail.com> wrote:

> On a related note - does it make sense to integrate futures with the events
> framework?
>
> Seems like touch is similar to sync.
>
> Cheers,
> yc
>
> On Sun, Dec 13, 2009 at 7:57 AM, James Swaine <james.swaine at gmail.com>wrote:
>
>> Right.  You won't have the problem Sam talks about where you've forced a
>> computation to finish on a separate OS thread than the one you originally
>> started on.  Code in a future will always execute on the same OS thread
>> (except for the unsafe primitive invocations), even if you touch it before
>> it's finished.  In that case, the runtime OS thread will do whatever unsafe
>> work was blocking the future, then signal the future OS thread that it can
>> resume.  Then the runtime OS thread blocks waiting for the future thread to
>> terminate (or ask for another primitive invocation).
>>
>> One thing to worry about is touching a future before a parallel thread has
>> had a chance to discover it, in which case the whole future will actually be
>> run on the runtime thread.  I don't think this would really ever be a
>> problem in practice, however, because if your code wants to touch the future
>> that quickly, you probably didn't need to do the computation in parallel in
>> the first place.
>>
>> The operating system can arbitrarily decide to move threads from one
>> processor to another but there's little we can do about that.  We can use
>> affinity masking to politely suggest that the OS keep threads bound to
>> specific processors/cores, but even then it's still
>> free to schedule them however it wants.
>>
>> -James
>>
>> On Sun, Dec 13, 2009 at 9:10 AM, Robby Findler <
>> robby at eecs.northwestern.edu> wrote:
>>
>>> On Sun, Dec 13, 2009 at 8:40 AM, Sam TH <samth at ccs.neu.edu> wrote:
>>> > I thought that when a future gets `touch'ed, if
>>> > it isn't finished, the remainder of the computation runs in the
>>> > continuation (and thus thread) of the `touch'.  If I'm wrong about
>>> > that, then my worries are assuaged.
>>>
>>> That's roughly what happens when the future was blocked (technically,
>>> it does some rendez vous with the runtime thread instead of copying
>>> the state over, but that's something that shouldn't really matter from
>>> the api level), but when the future is not blocked, it just keeps
>>> running merrily along.
>>>
>>> Robby
>>>
>>
>>
>> _________________________________________________
>>  For list-related administrative tasks:
>>  http://list.cs.brown.edu/mailman/listinfo/plt-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20091213/63a476ca/attachment.html>