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

[Gonzalo Diethelm]

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