[plt-dev] Parallel Futures Release

From: Eli Barzilay (eli at barzilay.org)
Date: Mon Dec 7 16:42:36 EST 2009

On Dec  7, James Swaine wrote:
> On Mon, Dec 7, 2009 at 1:08 PM, Eli Barzilay <eli at barzilay.org> wrote:
> > On Dec  7, James Swaine wrote:
> > > I'm pleased to announce the initial release of parallel futures, a
> > > construct for fine-grained parallelism in PLT.
> >
> > Random notes:
> >
> > 2. Is it possible to move `processor-count' into the core and make it
> >   available for non-future builds too?  That function is useful even
> >   without futures (for example, for code that runs subprocesses for
> >   all cores -- in my scripts I just read a from from /proc, and
> >   having a portable replacement would be nice).  For the sake of code
> >   that wants to use futures, I think that the current function is
> >   better named `futures-count'.
> >
> This sounds fine to me.  processor-count should always have the same
> behavior, regardless of whether futures are enabled.

Yes -- that was too implicit in my comment, sorry.

> But I'm not sure why you would need a separate function for
> futures-count, unless you're intending it to be related to question
> (6) below?

Not really -- I'm just thinking that people would want to know whether
futures are enabled, and `processor-count' is the way to do this now.
So if that always returns the number of cores, it's probably enough to
have a function that returns whether futures are available.

BTW, in addition to Sam's comment about turning a future into a thread
(which makes sense to me too) -- perhaps it's also good to make
`future' create a plain thread if there is no future support?  I think
that both of these are related in that futures are closer to (plain)
threads than they are to a promise.

> > 6. [...a list of the currently running futures...]
> > 7. [...disable futures...]
> > 8. [...kill a running future...]
> > 9. [...break when touching a future...]

I should have added that these are IMO important things to do before
it's turned on by default.

> An excellent point - I'll update the documentation to include
> something to this effect.  We've had several discussions about
> adding concurrency primitives with futures - but you're right, as of
> now you're restricted to independent tasks because there really
> isn't an effective way to do inter-thread communication.

Besides documenting it, the addition of some synchronization functions
(which was again too implicit) is in the above group of features.
(Ang again, that's IMO.)

          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

Posted on the dev mailing list.