I had that in mind, too... But I planned that way (subclassing of the
manager isn't possible... As there will be many implementations):

Instead of registering his event handler directly to the manager, a user
would have to register a kind of QueuingEventFilter that queues the
event and processes them asynchronously (using a configurable thread
manager). (and perhaps block when the queue is full)

> -----Urspr�ngliche Nachricht-----
> Von: Peter Donald [mailto:[EMAIL PROTECTED]] 
> Gesendet: Dienstag, 26. Februar 2002 21:01
> An: Avalon Developers List
> Betreff: Re: async connection manager... threading questions
> 
> 
> On Tue, 26 Feb 2002 23:46, Emperor wrote:
> > As you know I'm developing an async connection manager. I need two 
> > threads in my NBIO impl (one to accept and connect clients, 
> the other 
> > to get write and read events). Now I have two 
> possibilities: I could 
> > call the events handlers in the thread that received the 
> events, or I 
> > could perhaps use an internal event pipeline. So in fact 
> the question 
> > is wether to have an event queue integrated (processed by a thread 
> > pool) or to let the class that uses the manager implement this.
> >
> > What seems the best way?
> 
> I don't think there is *one* best way. I could see different 
> situations where 
> each may be useful. So you may want to have a baseclass that 
> does something 
> lke this
> 
> protected void handleEvent( Event e )
> {
>   process.event( e );
> }
> 
> and a subclass that overides it and puts it in a queue like
> 
> protected void handleEvent( Event e )
> {
>   m_queue.push( e );
> }
> 
> -- 
> Cheers,
> 
> Pete
> 
> The big mistake that men make is that when they turn thirteen 
> or fourteen and all of a sudden they've reached puberty, they 
> believe that they like women. Actually, you're just horny. It 
> doesn't mean you like women any more at
> twenty-one than you did at ten.                --Jules 
> Feiffer (cartoonist)
> 
> --
> To unsubscribe, e-mail:   
> <mailto:avalon-dev-> [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: <mailto:[EMAIL PROTECTED]>
> 
> 


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to