Thread Pooling

[Sean Kelly]

Craig Black wrote:
> 
> 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.

Compared to working directly with a thread pool, it allows for the 
scheduling policy to be separated from the task queue.  So actives could 
be run sequentially in the main thread, spread across multiple threads, 
etc.  However, a more general task processor could really do the same 
thing.  For the rest, I think it mostly provides a decent framework to 
use for asynchronous task completion.  For example, I think it's 
potentially useful to be able to wait on combinations of futures using 
or/and logic.

> 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();

I'll admit I skipped that part for the sake of brevity, but it should be 
possible to create active objects via subclassing or perhaps with a 
combination of mixins and interfaces.  However, I think the ad hoc 
approach may prove to be much more useful in practice.

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

Depends on the problem, I think.  I think the non-OO active syntax 
better illustrates just how easy it is to break sequential code into 
parallel chunks.

I'll probably have more to say once I've read the links Kris posted.


Sean