directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: [seda] Re: SEDA
Date Wed, 14 Jan 2004 16:15:04 GMT
Alex Karasulu wrote:

> Rich,
>>I doesn't use anything from sandstorm.  It just takes inspiration from it.  I
>>looked at it a while ago too and just revisited it today.  Before it didn't
>>really seem complete, but it does now.  And it seems simpler to me than the
>>Sandstorm implementation (though I don't think my understanding is complete

Yep, this summary is right on.

>>In the Excalibur event package there is no use of NIO or anyother kind of IO. 

Correct.  This is something that belongs in a library using event.

>>It has ThreadManager's which handle processing of events.  It has the
>>CommandManager which, in my understanding, represents a stage.  Then there are
>>a couple of queues (DefaultQueue grows, FixedSizeQueue doesn't).  There are a
>>couple kinds of Sinks (which is where my understanding is a bit short).  And
>>there are some EnqueuePredicates.  My biggest question in the existing event
>>package is how an event (called a Command in Excalibur events) moves from one
>>stage to the next.  I don't see any mappings between source and sink, though I
>>may be missing something.  From my understanding right now it seems the
>>EventHandler would decide what the next CommandManager (Stage) to which the
>>command (event) should be sent.

The ThreadManager is kind of like the "heartbeat" of the system.  The
ThreadManager handles the logic to interact with thread pools and send events
through the different stages.  Every Source/EventListener pair processes the
events regardless of whether they are connected or not.

A slight correction to the above paragraph:  ANY object can be an event, not
just commands.  The Command objects are the types of events that the
CommandManager stage understands how to use.  Another stage can use any other
object to do its work.

As long as an object implements EventHandler, it can be used as a stage (from
the ThreadManager's perspective).  The object implementing EventHandler may
in turn send events to another Sink.  Please note that a Queue is a pipe, so
it is both a Sink and a Source.  The ThreadManger can take any number of
Sources, and send all the events in them to one EventHandler.

The process of moving from Sink to Source is dependent on what you want to do.
In most cases, it is done by using a Queue so the movement is automatic and
natural.  There are special cases in the SEDA study that used dedicated Sources
to generate connection and socket reading events, and there are special cases
where there were dedicated sinks to send the results on.  In theory this is
right, but in practice all can be done with stages and only use queues to
connect those stages.


"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

View raw message