[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

Hi Alex,

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),
>                           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_,
>                                mask,
>                                ready_mask,
>                                et.event_handler_, 
>                                callback);
> 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,
>                            mask,
>                            ready_mask,
>                            this->handler_rep_.find (handle), // OK!
>                            callback);
> 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.



> Thanks,
> Alex.
> 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
>     to.
>     BTW, please see the ACE_ROOT/tests/Priority_Reactor_Test.cpp for some
>     examples of how to use the ACE_Priority_Reactor properly.
>     Thanks,
>            Doug
>     >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 mailing list