On 26 June 2004 02:48, Glynn Clements wrote:
You can't set the send/receive timeouts using that function; it always
passes a C int (with the optlen parameter set to sizeof(int)). You
would have to re-write it with a more flexible interface, e.g.:
import Foreign
import Foreign.C
import
On Thu, Jun 17, 2004 at 10:53:28AM +0100, I wrote:
Digging around in the source code comments, I found a restriction that
is biting me:
We *insist* that all overloaded type variables are specialised to ground
types, (and hence there can be no context inside a SPECIALIZE pragma).
The
Simon Marlow writes:
I'm tempted to replace the current setSocketOption with
this version. Would anyone object?
On the contrary. IMHO, the SockOption type should be
extended to contain the required parameter, for example:
data SocketOption
= Debug Bool
| ReuseAddr Bool
|
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
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
mån 2004-06-28 klockan 14.00 skrev Peter Simons:
Simon Marlow writes:
I'm tempted to replace the current setSocketOption with
this version. Would anyone object?
On the contrary. IMHO, the SockOption type should be
extended to contain the required parameter, for example:
data
There's no reason in principle. I looked into why it's not happening in
practice, and there is a reason, although it's not a good one.
Briefly, the way specialisation works is this:
* We find all calls to 'f' in this module
* We float them up to the definition of f, along with their
Hi!
On Mon, Jun 28, 2004 at 02:08:29PM +0200, Martin Sjögren wrote:
mån 2004-06-28 klockan 14.00 skrev Peter Simons:
Simon Marlow writes:
I'm tempted to replace the current setSocketOption with
this version. Would anyone object?
On the contrary. IMHO, the SockOption type should
Martin Sjögren writes:
Wouldn't that make
getSocketOption :: Socket - SocketOption - IO Int
a bit strange? How would you propose to change it?
Right, that is a problem. My first idea how to fix this
would be
getSocketOption :: Socket - SocketOption - IO SocketOption
as in:
Debug v
What would happen if a timeout occurs in the _socket_ level?
I believe a (unix) socket level problem (including remote server
closing the connection unexpectedly) results in a Posix SigPIPE.
Is you set the default action to ignore:
installHandler sigPIPE Ignore Nothing
Then it gets
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
Simon Marlow writes:
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.
Okay, thanks for the information! Looks like a racer thread
per timeout is the better approach after all.
Peter
If you fork a thread to handle each connection the async
exception is thrown to the (Haskell) thread which is
performing IO on the socket when it happens.
(the ignore means ignore the signal the default action is
to terminate the program)
Keean.
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
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
Simon Marlow wrote:
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?).
I suspect that the manual page may be outdated. 2.4 implements those
options; at least, setsockopt stores the value in the struct
16 matches
Mail list logo
