directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Wallace <rwall...@thewallacepack.net>
Subject Re: [seda] Re: SEDA
Date Wed, 14 Jan 2004 23:04:24 GMT
Great!  This helps my understading tremendously.

Thanks Berin,
Rich

On Wed, 2004-01-14 at 09:15, Berin Loritsch wrote:
> 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
> >>yet).
> 
> 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.


Mime
View raw message