There are several scenarios which I will describe where the
number_of_active_handles value becomes incorrect. If this value is incorrect,
the select reactor(ACE_Select_Reactor_T) may never exit it's while
loop(dispatch())trying to service the select bits. In other cases it will exit
the while loop after spinning until a timer expires. The loop I'm referring to
is dispatch(). I will try to describe some of the scenarios. I also accept the
possibility that my understanding may be inaccurate.

First the simplest to describe:
dispatch_notification_handlers and dispatch_notifications both decrement
number_of_active_handles when dispatching a single notification. This double
decrementing would/could cause the count to go <0.

dispatch_notificaiton_handlers decrements number_of_active_handles based upon
the return value from dispatch_notifications which could be the return value
from the handle_output. The two I thought was unrelated which could cause some
very unpredictable behaviour depending upon the handle_output return value
defined by some ACE user.

The one not easy to describe is next. First some pre-condition....
select finds that there are 2 handles both readable and writable (io or
notification, does not matter). The user then decides to remove a handler that
has not yet been dispatched. The select bit gets cleared but
number_of_active_handles does not get updated. Yes, the state_changed flag gets
set; however, resetting the iterator in dispatch_io_set or ignoring
state_changed in dispatch_notification_handlers will not change
number_of_active_handles. When dispatch() comes back to loop through,
number_of_active_handles does not reflect the number of select bits any longer.
This could result in spinning until a timer fires resulting in some other states
changeing and re-reading the select bits. Or another possibility is that the
loop returns pre-maturly which is not as severe I guess.

I hope this is somewhat clear and helps.