The future of concurrent programming

[BCS]

Robert Fraser wrote:
> 
> .... [snip]
> 
> At work, I'm using SEDA:
> 
> http://www.eecs.harvard.edu/~mdw/papers/mdw-phdthesis.pdf
> 
[...]
> 
> The general idea behind something like this is "fire and forget". There is a set of "stages", each with a queue of events, and a thread pool varying in size depending on load (all managed behind the scenes). The creator of a stage needs only to receive an event and process it, possibly (usually), pushing other events onto other stages, where they will be executed when there's time. Stages are highly modular, and tend to serve only one, or a small group of, functions, but each stage is managed behind the scenes with monitoring tools that increase and decrease thread count respective to thread load.
> 
[...]
> 
> Now only to port it to D...

This sounds somewhat Like an idea I has a while ago: Build a thread safe 
queue for delegates taking void and returning arrays of more delegates 
of the same type. Then have a bunch of threads spin on this loop

while(true) queue.Enqueue(queue.Dequeue()());

Each function is single threaded, but If multi threaded stuff is needed, 
return several delegate, one for each thread. Race conditions and 
sequencing would still be an issue but some administrative rules might 
mitigate some of that. One advantage of it is that it is somewhat 
agnostic about thread count.