Futurism lib (futures in D)

[Kevin Bealer]

== Quote from Daniel Keep (daniel.keep+lists at gmail.com)'s article
> Kevin Bealer wrote:
...
> Looks good; more sophisticated than my own.  A few initial thoughts:
>
> 1) Have you considered stealing my code and using the "future(...)"
> syntax I used?  It seems a bit cleaner than having to alias the class,
> and then instantiating objects.

I wanted the first checkin to be "stealing free" ;), but I was actually going to
ask if you minded me adapting the tuples interface from yours.  I guess not, so
I'll look at doing that then.

> 2) You say that ThreadPools must be stopped before being deleted.  Maybe
> it would be good to have a ThreadPoolScope class that must be scoped,
> and will call stop for you.

Couldn't hurt.

> 3) Speaking of the thread pools, have you considered creating a default
> pool with (number of hardware threads) threads?  I think std.cpuid can
> give you those numbers, but I don't know enough to say whether it would
> a good idea performance-wise.

I'm not sure about the design.  I originally had thread pools call stop() from its
own destructor, but of course that doesn't work because the Thread object can be
garbage collected first.

What I'm not sure of is this: all objects are garbage collected at program
termination, but static destructors (static ~this()) blocks are also called at
program termination.  Is there a guarantee that the GC runs after the ~this() blocks?

I would also recommend using more thread pool threads that hardware threads,
because some operations (like reading files) are IO bound, and the system benefits
if it can switch to a CPU bound thread.  So you always want at least the number of
hardware threads, but I think its a matter of tuning how many more than that.  If
you think each task is about 50% CPU bound, you might want something like 2x the
number of hardware threads.

> Again, it looks really good.  Might have to start using it myself :)
> 	-- Daniel

Thanks - I appreciate the suggestions, too.

Kevin