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

[Ganesh Pai]

Separate pipe are not a must. You can use one notification handler. However
if you do this then you will have then figure out which queue to read in the
notification handler.
For Select reactors, the only other solution I could think is polling the he
queues when select times out if you don't want to use pipes.

-----Original Message-----
From: Gonzalo Diethelm [mailto:gonzalo.diethelm at diethelm.org] 
Sent: Wednesday, February 20, 2008 3:41 PM
To: Ganesh Pai
Cc: 'Douglas C. Schmidt'; 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