avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [Review] Event Queues
Date Mon, 17 Dec 2001 19:24:51 GMT
Leo Sutic wrote:

> 
>>Ok, now with the actual problem at hand.  The typesafe interface 
>>would be handy, but I have to wonder *how* to practically use it.  
>>The issue is that I want the same feel for both C++
>>as well as Java if that is how you are working with it.
>>
>  
> 
>>I want to stay away from strings being the signal type, and if 
>>possible, the class type
>>being the signal type.
>>
> 
> if (a instanceof A)     <-------->  if (dynamic_cast<A> (a) != NULL)
>      Java                                          C++
> 
> There are ways to solve this, with a switch/case construct. But I 
> want to get rid of the construct.


:/


> 
> Ideally, one would introduce a layer in front of the Sink, and one after 
> the Source, and by magic be able to write code like this:
> 
> class MyStage extends AbstractStageWrapper {
> 
>   public void handleConnectionOpen (ConnectionOpenEvent event) {
>      ...
>   }
> 
>   public void handleConnectionClosed (ConnectionClosedEvent event) {
>      ...
>   }
> 
> }


I see.  In Java, this is pretty expensive.  I can see how it would be
helpful, but you now would have to approach it like Swing does.  There
are specific events a Swing Handler of a certain type can handle.  An
extension of an EventHandler would be able to farm out those types of
events and encapsulate the switch/case logic in that EventHandler.

That would be the way to minimize the cost of creating a Method object,
and invoking it--done several hundred times a second, and now you are
thrashing your Garbage Collection.

In many cases, the switch/case would not only be sufficient, but preferred.
In other cases, the separate EventHandler that calls methods on the
Stage object would be better.  For example:

class MyStage implements Stage, ConnectionHandler {
     public void handleConnectionOpen( Connection conn ) { ... }
     public void handleConnectionClosed( Connection conn ) { ... }
     public void handleEvent( QueueElement event ) { ... }
}

class ConnectionDistributionHandler
{
     private final ConnectionHandler m_target;

     public ConnectionDistributionHandler( ConnectionHandler target )
     {
         m_target = target;
     }

     public void handleEvents( QueueElement[] events )
     {
         int len = events.length;
         for (int i = 0; i < len; i++)
         {
             switch ( events[i].getType() )
             {
                 case CONNECTION_OPEN:
                     m_target.handleConnectionOpen( (Connection) events[i].getAttachment()
);
                     break;

                 case CONNECTION_CLOSED:
                     m_target.handleConnectionClosed( (Connection) events[i].getAttachment()
);
                     break;

                 default:
                     m_target.handleEvent( events[i] );
             }
         }
     }
}

Using reflection is pretty expensive for this type of thing.


> 
> Which, as I think about reflection, one actually can. Does anyone
> know the performance penalty for dynamic invocation of methods,
> as related to the expected time to run a typical SEDA event handler?
> 
> I just want to get rid of that cursed switch/nested if!


You would have to abstract it out to specific subsystems....


> 
> In C++ I think I could do it with some macros.
> 
> Summary: As far as the Queue interfaces go, go for it. I don't
> think you can get them any better without trying to use them.
> They have no apparent faults.
> 
> Just trying to wrap my head around the SEDA stuff and how to best
> express the architecture in Java/C++. I want as direct a mapping
> between the language and the concepts as possible, and I do not
> think the current implementation of SEDA is that.


I think now is time to actually create the implementations of the
interfaces.




-- 

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


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message