[plt-dev] Parallel Futures Release

At Mon, 7 Dec 2009 16:42:36 -0500, Eli Barzilay wrote:
> perhaps it's also good to make
> `future' create a plain thread if there is no future support?

I don't think that's the right idea.

To me, that's like suggesting that on platforms where the FFI is
unsupported, the relevant functions should manufacture procedures that
randomly corrupt memory. Its true that the FFI offers the capability to
randomly corrupt memory, and that feature is inescapable given the
FFI's job. But it's not really the point.

Similarly, by way of offering potentially reduced run times, it happens
that futures offer some visible concurrency (and, yes, the docs need to
be clearer about it). That's not really the point, though.


> > 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.

This also doesn't make sense to me. When `(processor-count)' produces
1, it doesn't matter whether MzScheme was built with `--enable-futures'
or not; the resulting lack of performance improvement is the same
either way.