Carsten Schultz wrote:
Wouldn't that make
getSocketOption :: Socket -> SocketOption -> IO Int
a bit strange? How would you propose to change it?
Possible, but also possibly overkill, would be:
newtype Debug = Debug Bool
newtype SendBuffer = SendBuffer (Maybe Int)
[...]
class SocketOption a where [
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 so
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 re
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 n
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:
> 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
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 w
>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 con
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:
D
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 SockOpti
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:
>
>
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.
>
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
happ
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
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
>> i
Peter Simons wrote:
> the Network module provides the data type SocketOption. I am
> particularly interested in setting the RecvTimeOut and
> SendTimeOut values, but I wonder how to set them. The
> function
>
> setSocketOption :: Socket -> SocketOption -> Int -> IO ()
>
> allows me only 'Int'
Hi,
the Network module provides the data type SocketOption. I am
particularly interested in setting the RecvTimeOut and
SendTimeOut values, but I wonder how to set them. The
function
setSocketOption :: Socket -> SocketOption -> Int -> IO ()
allows me only 'Int' parameters, but the kernel expec
17 matches
Mail list logo
