[Ace-users] [ace-users] Basic Reactor concepts

Gonzalo Diethelm gonzalo.diethelm at diethelm.org
Wed Feb 20 15:09:11 CST 2008


Excellent, thanks Steve. In fact, I am pretty sure this is exactly what
I had done once, a long time ago, and also due to your suggestion; I
believe this is what sounded to me similar to what Ganesh was proposing.

Two questions:

1. Will this work with the TP_Reactor? I mean, when the strategy
notifies the reactor, will all threads in the reactor eventually be used
to handle the notifications?

2. Will this work on Win32, with / without the TP_Reactor?

Thanks and best regards.

On Wed, 2008-02-20 at 15:59 -0500, Steve Huston wrote:
> Check out ACE_Reactor_Notification_Strategy. There's also an
> explanatory piece in the ACE Knowledge Base at
> http://www.riverace.com/ace-kb.htm - search for "notifications"
> 
> Best regards,
> -Steve
> 
> --
> Steve Huston, Riverace Corporation
> Want to take ACE training on YOUR schedule?
> See http://www.riverace.com/training.htm
> 
> 
> > -----Original Message-----
> > From: ace-users-bounces at cse.wustl.edu 
> > [mailto:ace-users-bounces at cse.wustl.edu] On Behalf Of Gonzalo
> Diethelm
> > Sent: Wednesday, February 20, 2008 3:41 PM
> > To: Ganesh Pai
> > Cc: ace-users at cse.wustl.edu
> > Subject: Re: [ace-users] Basic Reactor concepts
> > 
> > 
> > Thanks Ganesh. The approach you state rings a bell with me, I 
> > am sure I
> > have done something similar. Could this be done without having the
> > pipes, and only an event handler for each queue? The, when 
> > messages are
> > deposited on the queue, could I achieve the same result by 
> > just calling
> > reactor->notify(event_handler)? Or are the separate pipes a must?
> > 
> > Thanks and best regards.
> > 
> > On Wed, 2008-02-20 at 15:11 -0500, Ganesh Pai wrote:
> > > Here is how I have solved this problem. This approach is 
> > for reactors based
> > > on select/poll/epoll + Leader Follower pattern.
> > > 
> > > * For each of the N queues, associate a pipe + event handler 
> > > * Plug the event handler into the reactor
> > > * Using TP reactor you could then have M threads which run the
> > >   Reactor loop
> > > * Whenever messages are deposited into the queues, the associated 
> > >   pipe has to be notified
> > > * One of the M threads would handle the pipe (handle_input) 
> > and process
> > >   the message from the associated queue
> > > 
> > > Hope this helps. The key to the above approach was the 
> > understanding that
> > > select works only on some I/O handle. By associating a 
> > notification handle
> > > (pipe) with each work queue makes the TP reactor now a 
> > de-multiplexer for
> > > message queues as well.
> > > 
> > > 
> > > -----Original Message-----
> > > From: ace-users-bounces at cse.wustl.edu
> > > [mailto:ace-users-bounces at cse.wustl.edu] On Behalf Of 
> > Douglas C. Schmidt
> > > Sent: Wednesday, February 20, 2008 2:13 PM
> > > To: Gonzalo Diethelm
> > > Cc: ace-users at cse.wustl.edu
> > > Subject: Re: [ace-users] Basic Reactor concepts
> > > 
> > > 
> > > Hi Gonzo,
> > > 
> > > > Again, I am trying to lessen my ignorance here...
> > > 
> > > Always a laudable goal ;-)
> > > 
> > > > Although I have always seen the Reactor as a key piece in 
> > the Acceptor
> > > > / Connector / Svc_Handler class family in ACE, used to 
> > process I/O, a
> > > > Reactor seems to be a generic concept for solving the following
> > > > requirement, right?
> > > > 
> > > > "Decouple the reception of events from its processing, in 
> > a way that,
> > > > for instance, makes it possible to receive events in one 
> > thread and
> > > > process them in a different thread".
> > > 
> > > This is actually a different set of POSA2 patterns, e.g.,
> > > Half-Sync/Half-Async or Active Object.  You should start by
> reading
> > > about them.  The Reactor pattern can be used as part of the
> > > implementation of Half-Sync/Half-Async pattern.
> > > 
> > > > Now, for me to understand this better, let me pose an 
> > example to you and
> > > > maybe someone can indicate, if I am correct, how such an 
> > example would
> > > > be handled with a Reactor. Say I have N message queues; 
> > they are all
> > > > filled via some kind of opaque process which does not 
> > concern us, except
> > > > for the fact that each queue is filled totally 
> > independent from the
> > > > others (for example, one queue could store mouse events, 
> > another could
> > > > store serial port incoming data, etc.). Now, I wish to 
> > have M threads
> > > > (M != N) running in parallel, with an identical, simple 
> > infinite loop
> > > > that will fetch an event from a queue that has signalled 
> > it has events
> > > > available, and then process this event.
> > > > 
> > > > If I am right in my assumptions about the Reactor's 
> > purpose in life, 
> > > 
> > > This isn't really the Reactor's purpose in life, unless 
> > those N queues
> > > happen to be the appropriate type of OS handle than can be 
> > waited upon
> > > together via a "synchronous event demuxer".
> > > 
> > > > how do I wire things in this scenario in order to have 
> > the N queues
> > > > use a Reactor to notify the M threads for processing?
> > > 
> > > I think you're better off using the Half-Sync/Half-Async 
> > pattern here,
> > > so please start by looking at it first.
> > > 
> > > Thanks,
> > > 
> > >         Doug
> > > 
> > > _______________________________________________
> > > ace-users mailing list
> > > ace-users at mail.cse.wustl.edu
> > > http://mail.cse.wustl.edu/mailman/listinfo/ace-users
> > > 
> > > 
> > 
> > -- 
> > Gonzalo Diethelm
> > gonzalo.diethelm at diethelm.org
> > 
> > _______________________________________________
> > ace-users mailing list
> > ace-users at mail.cse.wustl.edu
> > http://mail.cse.wustl.edu/mailman/listinfo/ace-users
> > 
> 
> 
> 

-- 
Gonzalo Diethelm
gonzalo.diethelm at diethelm.org



More information about the Ace-users mailing list