The notify  () calls in the critical path creates dangling references to
connection handlers within the ORB. 
When the ORB is doing something like this:

1 Receive two simultaneous requests on one event handler.
2 Queue the second request using the notify() trick.
3 Send the response to the first request.
4 Ooops, the connection is broken (client died), close the connection.
5 Delete the event handler.
6 Dequeue the notification and try to use the event handler.
7 Ooooooooooops, the event handler in the notification pipe/queue is invalid
8 Crash.

Solutions like purging the notify calls between 4 and 5 dont work if the notify
mechanism used is a pipe. There are two possible solutions to this. Both of them
are centered around incrementing the refcount of the connection handler. Here
are the ideas 

- Increase the reference count every time the Connection_Handler is put through
the notification mechanism.  Then decrement the count on handle_input(), but
only if the ACE_HANDLE parameter is ACE_INVALID_HANDLE.    This only works if
notifications have an invalid handle, while normal events have the right handle.
 Reading the code confirms this, but I'm not sure if there is a "promise" that
this will be the case.

- Instead of sending a notification to the TAO_Connection_Handler create a
helper Event_Handler, something like:

class TAO_Notifier : public ACE_Event_Handler
{
public:
  TAO_Notifier (TAO_Connection_Handler * ch) : ch_(ch)
  {
     // increase ch refcount
  }
  virtual ~TAO_Notifier()
  {
     // decreate ch refcount
  }
  virtual int handle_input(ACE_HANDLE h)
  {
    (void) ch_->handle_input(ch);
    return -1; // Automatically commit suicide...
  }
}

Thus the temporary object is created for each notification, and it
automatically keeps the reference count too.

In both cases we need to ensure that all notifications are indeed executed,
otherwise we will leak resources at the end of the day.