simonmar at microsoft.com
Mon Jun 28 08:33:59 EDT 2004
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?).
More information about the Glasgow-haskell-users