Hi Göran,

> I don't really now why this code looks like it does but I do 
> wonder why the unix version notifies the readSemaphore even
> if the socket is not "socketReadable".

It doesn't. It just puts it into the asynchronous handler list (this is
what aioHandle() does). Only when the socket becomes readable (as
determined by select()) it will be signaled.

> I don't really know what aioHandle is/does but I
> assume it will result in that "notify()" is called which in 
> turn signals the readSema.

See above. It appears to me that there must be some mismatch in
aioPoll() and socketReadable(); from your example it looks like
aioPoll() is calling the dataHandler() which signals the semaphore but
socketReadable() returns false in response to the query for data.

Hm ... I had a similar problem a while ago which I tracked to the
problem of not handling socket errors correctly (e.g., almost all of the
socket error codes imply that the socket is no longer connected but the
error handling code did not mark the socket as closed). This lead to a
similar situation.

[Note to Ian: But you need to keep in mind that for UDP sockets there is
no such state as "OtherEndClosed". Those have to stay "Connected" no
matter what - I just ran into this problem]

> Obviously I am missing something fundamental here -
> shouldn't the readSemaphore only be signalled if there is something to
> read? On Win32 it seems to never signal the semaphore which also
> seems.... funny. :-)

Same thing on Windows - the semaphore is signaled asynchronously from
within the [read|write]WatcherThreads.

Cheers,
  - Andreas