On 28 June 2004 13:06, Peter Simons wrote:
Glynn Clements writes:
Am I even supposed to set them, or is there a better way to specify general I/O timeouts than on the socket level?
Non-blocking I/O and select/poll; although I don't know how well that is supported.
Can anyone tell me how well supported it is? What would happen if a timeout occurs in the _socket_ level? Will an exception be thrown? Can I count on this behavior even when reading from a socket (read: a Handle promoted from a Socket) with hGetContents?
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, but the usual way to do this is to fork another thread to sleep and send an exception to the original thread. Code for a timeout combinator has been posted to this list before (try Google). Cheers, Simon
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. Peter
participants (2)
-
Peter Simons -
Simon Marlow