Thread Pooling

[Sean Kelly]

Craig Black wrote:
>> I've considered this as well.  In fact, I've got library code to do this 
>> for C++.  But I'd prefer something a bit more forward-looking for D (see 
>> Herb Sutter's Concur project for one possibility).  I'm planning to 
>> address this need at some point in Ares, probably in a manner similar to 
>> the Concur design, but I don't have time at the moment.
> 
> I don't see syntax this high-level to be implementable in a library.  It 
> seems like this would require features to be added to the language core.  Or 
> do you disagree?

I don't think the exact syntax matters so much as behavior and ease of 
use, though inner functions and delegates should allow us to get fairly 
close without any language changes.  The most obvious approach would be 
something like this (note that I haven't given this much thought so it 
may require some changes):

     auto x = active( void delegate() { foo(10); } );
     auto y = active( void delegate() { a.b(c); } );
     auto p = active( Bar  delegate() { return new Bar; } );
     (p & (x | y)).wait(); // waits on a temporary future group
     return p.val;

Here, the 'active' keyword has been replaced by a function accepting a 
delegate, and future group logic uses bitwise operators instead of their 
logical operators (operating a bit like simple expression templates). 
Also, the 'val' member is used in place of implicit type conversion to 
get at the returned value, if one exists.

This sort of thing seems preferable to explicit use of threads and 
locks, but I feel it's merely the first step towards something better. 
Hopefully, better ideas will present themselves once we have a chance to 
play with the idea a bit, as I'm not sure I'd actually propose language 
changes to support this sort of thing quite yet.


Sean