[plt-dev] Parallel Futures Release

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/fb81a3a3/attachment.html>