I've been debugging some code which admittedly does not conform to a well-
formed use of the proactor pattern.  In this case, the original developer chose 
to synchronously connect to an endpoint (TCP) using an ACE_SOCK_Connector.

ACE_SOCK_Stream strm;
ACE_SOCK_Connector connector;
...
if (connector.connect(strm, address) == -1)
...

The connection occurs properly and the code then tries to monitor that 
connection using the Proactor.  Its done using a pair of streams (writeStream_ 
and readStream_).  The streams are opened in the normal fashion.

if (readStream_.open(*this, _handle, _pCompletionKey) == -1)

Where: handle = strm.get_handle()

Then he calls readStream_.read() to start the process of reading from the 
stream.

The problem is that doing it this way does not generate any completion event 
and thus putq_result is never called.  I'm guessing under Windows this is no 
problem, but under Linux the following occurs.

Proactor thread start
Proactor creates the notify_manager and its pipe
Proactor starts an aio_read on the pipe which is in slot[0] of the aiocb_list_
Proactor handle_events_i goes into aio_suspend
Connection is created
IO stream is created and read is called
Proactor start_aio and start_aio_i are called which create the entry in the 
aiocb_list_, but do __not__ send any notification
Method returns and there is never a notification sent to the proactor to reset 
its state so that it handles the new connection

The result is the proactor sits in handle_events_i waiting for a control block 
and never receives one.  Meanwhile the connection never gets processed.

While the usage isn't true to the pattern it shouldn't cause it to fail like 
this.  For now, the solution I'm going to put in place is to post a completion 
to simulate the connection.