K P SCHUPKE writes:

I believe a (unix) socket level problem (including remote server closing the connection unexpectedly) results in a Posix SigPIPE.

No, it's an ordinary failure in the read()/write() operation. Quoting from socket(7): | SO_RCVTIMEO and SO_SNDTIMEO | Specify the receiving or sending timeouts until | reporting an error. The parameter is a struct timeval. | If an input or output function blocks for this period | of time, and data has been sent or received, the | return value of that function will be the amount of | data transferred; if no data has been transferred and | the timeout has been reached then -1 is returned with | errno set to EAGAIN or EWOULDBLOCK just as if the | socket was specified to be nonblocking. If the timeout | is set to zero (the default) then the operation will | never timeout. Turns my earlier statement about setting errno to ETIMEDOUT wasn't quite correct. :-)

Is you set the default action to ignore:

installHandler sigPIPE Ignore Nothing

Then it gets converted to an asynchronous exception...

I am not sure I understand this: If I say _Ignore_, then an asynchronous exception will be thrown? Would the exception tell me _which_ Socket had the error? It would be raised in the main thread, right? How could I tell which Socket had the timeout if I used more than one? Peter