[Ace-users] [ace-users] Basic Reactor concepts
Douglas C. Schmidt
schmidt at dre.vanderbilt.edu
Wed Feb 20 14:00:29 CST 2008
> 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
More information about the Ace-users