[plt-dev] Parallel Futures Release

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!