[ace-users] use of ACE_HAS_REACTOR_NOTIFICATION_QUEUE in Select Reactor

Douglas C. Schmidt schmidt at dre.vanderbilt.edu
Mon Aug 6 12:02:42 CDT 2007

Hi Prem,

Thanks for using the PRF.

>     ACE VERSION: 5.5.10
>     HOST MACHINE and OPERATING SYSTEM: Solaris 10 - X86
>         If on Windows based OS's, which version of WINSOCK do you
>         use?:
>     TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
>     THE $ACE_ROOT/ace/config.h FILE [if you use a link to a platform-
>     specific file, simply state which one]: enable-ipv6, IPV4_IPV6_MIGRATION
>     THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE [if you
>     use a link to a platform-specific file, simply state which one
>     (unless this isn't used in this case, e.g., with Microsoft Visual
>     C++)]:
>     CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features
>     (used by MPC when you generate your own makefiles):
> [What example failed?  What module failed to compile?] none
>         COMPILATION? none
>         LINKING? none
>             On Unix systems, did you run make realclean first?
>         EXECUTION? none
>         OTHER (please specify)?
> [Please indicate whether ACE, your application, or both are affected.]
> [Brief description of the problem]
> [Detailed description of problem.  Don't just say "<blah>
> doesn't work, here's a fix," explain what your program does
> to get to the <blah> state. ]
>     REPEAT BY:
> [What you did to get the error; include test program or session
> transcript if at all possible.  ]
> [If available ]
> Question: what is the use of ACE_HAS_REACTOR_NOTIFICATION_QUEUE in
> Select Reactor, calling schedule_timer (from a different thread - not
> the reactor thread of execution) seams to create a dead-lock at times
> (when the reactor does not have any events to process). I didn't face
> this problem when i compiled ACE enabling this macro (i didnt know why
> i really used this in first place!!!) ... just want to make sure what
> is the real use of the macro.

There's a discussion of this macro in a sidebar of Chapter 4 in C++NPv2
<www.cs.wustl.edu/~schmidt/ACE/book2/>.  Here's a synopsis:

In some situations, it's possible that a notification queued to an
ACE_Select_Reactor won't be delivered until after the desired event
handler is destroyed.  This delay stems from the time window between
when the notify() method is called and the time when the reactor reacts
to the notification pipe, reads the notification information from the
pipe, and dispatches the associated callback.  Although application
developers can often work around this scenario and avoid deleting an
event handler while notifications are pending, it's not always possible
to do so.

ACE offers a way to change the ACE_Select_Reactor notification queueing
mechanism from an ACE_Pipe to a user-space queue that can grow
arbitrarily large.  This alternate mechanism offers the following

. Greatly expands the queueing capacity of the notification
  mechanism, also helping to avoid deadlock.

. Allows the ACE_Reactor::purge_pending_notifications()
  method to scan the queue and remove desired event handlers

To enable this feature, add #define ACE_HAS_REACTOR_NOTIFICATION_QUEUE
to your $ACE_ROOT/ace/config.h file and rebuild ACE.  This option is not
enabled by default because the additional dynamic memory allocation
required may be prohibitive for high-performance or embedded systems.

It would be helpful for you to modify one of the Reactor tests in
ACE_ROOT/tests/ to demonstrate the bug if possible. 



More information about the Ace-users mailing list