Thread Pooling

[Craig Black]

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

I realize that you haven't had time to think this through completely, so 
perhaps I can help to stimulate your thinking.  And as always,  I could be 
missing something here so correct me if I'm way off base.

What benefit does this approach have over a thread pool?  It seems to be 
basically the idea that I had originally presented, except that I had not 
presented a solution for methods with return values.

The approach that you outline does not allow for active classes and so 
misses a large part of what the Concur pseudocode syntax provides.  For 
example,

active class C {
  void f() { ... }
  void g() { ... }
}
...
active C c;
c.f();
c.g();

Both of the above method calls are assigned to the same thread.  Thus, they 
are executed in order and not in parallel.  This is important, since they 
have access to common data members declared in class C.  How does your 
approach provide for this case?  Would we not have to revert to using locks?

In order to assign tasks to the same thread, we could make the active() 
method take one or more delegates.  Each delegate in the argument list would 
be assigned to the same thread and so would be executed in order rather than 
in parallel.

Even still, this approach lacks the OO elegance of the active class 
pseudocode.  But it's perhaps better than using locks.

I will, however, refrain, as much as it pains me to do so, from making any 
more feature requests for D until 1.0 is released. (Not a promise but I will 
try :)

-Craig