On 28 June 2004 13:17, Peter Simons wrote:
Simon Marlow writes:
The runtime uses non-blocking I/O and select() internally in order to support multi-threaded I/O. We don't have any direct support for timeouts [...]
Thanks for the clarification. I understand that.
But what would happen if I _do_ set a timeout on the socket level nonetheless? The timeout would strike in form of a read() or write() call returning -1 with an errno of ETIMEDOUT, so clearly it would be noticed by the RTS. The question is: will the RTS report the failure to me through an asynchronous exception?
Because if it does, then that is all the "support" I'll ever need, it saves me from 'forkIO'ing a racer thread for every operation that might time out.
The POSIX spec says that if I/O on a socket times out, then the operation will return EAGAIN or EWOULDBLOCK (there's no ETIMEOUT). It doesn't say what happens to select() on a socket that times out, so I'm not sure what will happen if you try this in GHC. The Linux socket(7) man page seems to say that you can't set SO_RCVTIMEO or SO_SNDTIMEO on Linux (but perhaps you can with a 2.6 kernel?). Cheers, Simon