Code examination of ACE_TP_Reactor::handle_socket_events reveals several subtle
and somewhat hard to reproduce race conditions, I'm not positive they do exist,
but I will need very solid arguments to believe otherwise.

1) The code releases the guard and then uses an event handler.  Yes, the handler
is suspended to avoid multiple threads from calling handle_XXX(), but there is
no guarantee that the application will not call remove_handler(..., DONT_CALL)
and then remove the handler.  Nor can the application find out if the handle is
suspended and therefore in the middle of an upcall.
    In other words, the TP_Reactor is at risk of using released memory, small
risk, but a real one.

2) After returning from dispatch_socket_event() the code calls:
    this->handler_rep_.find()
   the code there has no locks, and the data structure is shared.  Though we are
lucky in that there is little chance of memory faults corruption (the structure
is fixed size), there is still risk of reading invalid or inconsistent data.

I think race 2 can be fixed by re-acquiring the guard after coming back from the
dispatch_socket_event() call, however, the first race condition cannot be fixed
without more cooperation between the Reactor and the application.

I would suggest using the fixes attached to bug 1020, but if that was not
possible then we need to precisely define how are applications supposed to avoid
this problem.