> Bad ... I just looked at the plugin side of it and it turns out that the
> code for receiveDataAvailable _cannot_ return an error code. The return
> code is converted into a boolean and any non-zero return value will be
> interpreted as "true". There ya go. Gotta check my own code now.

Well spotted!

FWIW, I've looked over the socket code and I can't see any obvious
reason for the "extraneous" signals.  The semaphores are "enabled" (or
"armed" or "primed" or whatever) in precisely those two places implied
by John Mc's socket document (i.e., recvDataAvail and sendDone).
`pendingEvents' (local to each socket) is ORed with a mask indicating
if read and/or write signals are wanted.  If select() finds that a
socket is readable/writable then it invokes dataHandler() for the
socket; if dataHandler() sees that the socket's read and/or write
sempahore is "enabled" (corresponding bit set in pendingEvents) then
the sempahore(s) is/are signaled before resetting pendingEvents to
zero.

The logic seems infallible.

On the other hand, there *does* seem to be a problem with the use of
recvDataAvail and sendDone as "guard clauses" (John's words, my quotation
marks).  If the timeout expires before the semaphore is signaled, the
semaphore remains "enabled".  A subsequent change of state on the socket
will signal the semaphore, even though the image is no longer waiting on
it.  This additional "excess signal" seems to be the one that you (Goran)
are seeing -- although it's difficult to see how the signal gets there in
the first place, since senders of waitForDataUntil: tend to raise an error
if the deadline expires.  Hmm...

BTW, I suspect that your "initSignals" hack might work if you move the
send of initSignals to the beginning of the method; i.e., send initSignals
just _once_, and do it _before_ the first send of recvDataAvail.

(This is not the right solution though, and I don't endorse it in any way,
since there is a still race between the return from initSignals [which can
checkForInterrupts, causing i/o semaphores to be signaled] and the
subsequent send of recvDataAvail.  Caveat emptor.)

TTFN,

Ian