[Ace-users] [ace-users] Problem with ACE_Priority_reactor
Douglas C. Schmidt
schmidt at dre.vanderbilt.edu
Fri Oct 19 05:32:04 CDT 2007
Thanks very much for your email. Please make sure to send all
questions related to TAO or ACE to the ACE mailing list or ACE+TAO
newsgroup, rather than to me directly since I travel frequently and
often don't have ready access to email. See
for more info on how to access these resources.
> I am running ACE 5.5 and currently experiencing a problem with the ACE_Priority_Reactor.
Although it probably won't help your current problem with
ACE_Priority_Reactor, I recommend you upgrade to ACE+TAO+CIAO x.6.1
(i.e., ACE 5.6.1, TAO 1.6.1, and CIAO 0.6.1), which you can download
under the heading: "Latest Beta Kit."
The DOC groups at Washington University, UC Irvine, and Vanderbilt
University only provide "best effort" support for non-sponsors for the
latest release, as described in
Thus, if you need more "predictable" help for earlier versions of
ACE+TAO, I recommend that you check out
for a list of companies that will provide you with ACE+TAO commercial
> As I wrote before when I call
> remove_handler the process crashes.
> By now I can see the problems in the code.
> There are two problems - ( I relate here to the file Priority_Reactor.cpp)
> In build_bucket() we have the following lines -
> ACE_Event_Tuple et (this->handler_rep_.find (handle),
> int prio = et.event_handler_->priority ();
> Which is a problematic since the find() can return a NULL pointer, thus priority() method can crash.
Good point - I've fixed this. Please see
and let me know if this works better.
> This is not what cause my code to crash though. My problem is that in dispatch_io_set() we first enter the handlers
> themselves to the buckets (in build_bucket ()) and later on in the while loop , we call their notify_handle() method
> without checking again their validity.
> We call
> this->notify_handle (et.handle_,
> where the et.event_handler can be invalid by now.
> Just to compare to the good code in the Select_Reactor - it does the following:
> this->notify_handle (handle,
> this->handler_rep_.find (handle), // OK!
> which is ok, since if the handler was removed the find(handle) returns NULL and this is checked in notify_handle.
Please let me know if the fix mentioned above solves this problem.
> On 9/22/07, Douglas C. Schmidt <schmidt at dre.vanderbilt.edu> wrote:
> Hi Alex,
> To ensure that we have proper version/platform/compiler information,
> please make sure you fill out the appropriate problem report form
> (PRF), which is in
> or in
> in older versions of ACE+TAO. Make sure to include this information
> when asking any questions about ACE+TAO since otherwise we have to
> "guess" what version/platform/compiler/options you've using, which is
> very error-prone and slows down our responsiveness. If you don't use
> the PRF, therefore, it is less likely that someone from the core
> ACE+TAO developer team will be able to answer your question.
> Naturally, we encourage and appreciate other members of the ACE+TAO
> user community who can respond to questions that they have the answers
> BTW, please see the ACE_ROOT/tests/Priority_Reactor_Test.cpp for some
> examples of how to use the ACE_Priority_Reactor properly.
> >I was using the default reactor implementaion and I switched to work
> >with ACE_Priority_Reactor implementation. I have 40 sockets
> >(ACE_Event_Handlers) managed by it.
> >When I decide to close them my application crashes and in the debugger
> >I see that in dispatch_io_set, the handlers I have just removed (using
> >remove_handler) are bring still manipulated by the reactor.
> >Is it a known bug? Did I do something wrong?
> Dr. Douglas C. Schmidt Professor and Associate Chair
> Electrical Engineering and Computer Science TEL: (615) 343-8197
> Vanderbilt University WEB: www.dre.vanderbilt.edu/~schmidt
> Nashville, TN 37203 NET: d.schmidt at vanderbilt.edu
More information about the Ace-users