Re: SEDA batchController and stage overloaded

--- Eric Anderson <[email protected]> wrote:
> Maybe it would make sense to write a blocking patch to SEDA?  I know that might
> sound like blasphemy, but there seem to be a number of situations in which it
> makes sense.

Patching seda... You meant patching sandstorm.
SEDA is a pattern, or a concept. Sandstorm is one implementation of it.

For me, SEDA is just a specialization of the larger concept of thread management and interthread
comms. Matt proposed a framework for it, in the particular case of non-blocking tasks.

The fact that it has the non-blocking requirements only come from the choice of a threadpool
thread manager (TPSTM). The reason is very simple: since the TM must be able to remove a thread
from a stage's pool, this stage must be doing its work pretty quick (blocking or not). Otherwise
the thread would not return fast enough to the TM. Non-blocking is a requirements because it
wouldn't work nicely (thread pools would go crazy). 

Once you allow blocking stages, it is really just task runner with the very cute capability of
boosting the stages that are slow. My new engine fits both SEDA and "SDDA" (staged data driven
arch., if I may invent an acronym).



		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com