[Ace-users] [ace-users] Basic Reactor concepts
shuston at riverace.com
Wed Feb 20 14:59:17 CST 2008
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"
Steve Huston, Riverace Corporation
Want to take ACE training on YOUR schedule?
> -----Original Message-----
> From: ace-users-bounces at cse.wustl.edu
> [mailto:ace-users-bounces at cse.wustl.edu] On Behalf Of Gonzalo
> 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
> > 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
More information about the Ace-users