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

[Douglas C. Schmidt]

Hi Folks,

> The assumption about a Reactor's purpose is correct, but your example adds another layer of complexity.  A Reactor
> processes events, not queues.

Even more specifically, a Reactor's "synchronous event demuxer" waits on
set of handles.  These handles are triggered by so-called "indication
events" when there's something for the reactor to process.  Examples of
said handles would be sockets, file descriptors, terminal handles, etc.

> It dispatches the handling of these 'events' to (of course) Event
> Handlers.  Your example cites queues with each queue possibly
> containing events that need processed.  But the events that are placed
> in the queues are not the "events" that the Reactor would process.
> The Reactor 'event' in this case is the fact that a queue needs
> serviced.  This might be handled by a counting semaphore tied to each
> queue, with the semaphores themselves somehow registered with the
> Reactor (this is a good fit for how things work on Windows with
> WaitForMultipleObjects (the ACE_WFMO_Reactor) -- I'm not sure how well
> it extends to ACE Reactors that use select() under the hood).

It gets ugly fast ;-)

> Now we get to the second part of the assumption:  The "...process them [events] in a different thread" part is an example
> of what you can do with a Reactor *framework*, but it doesn't define how a Reactor works.  Dispatching events to your own
> worker threads is not built into the Reactor itself.  That would be the job of the Handler -- it's up to your Handlers to
> dispatch the events to the worker threads.  So your Handler would extract the latest entry in the queue that was signaled
> to wake the Reactor, then pass that entry off to (possibly) some other queue leading to a worker thread pool.

Right, which is what the "request queue" does in the
Half-Sync/Half-Async pattern!

Doug