On Fri, May 18, 2001 at 09:02:51PM +0100, Alan Cox wrote:
> > What I'm seeing however in an other program is that select says I
> > can read from the socket, and that read returns 0, with errno set
> > to EGAIN. I call select() again, with returns and says I can read
>
> No no no. If the read
> What I'm seeing however in an other program is that select says I
> can read from the socket, and that read returns 0, with errno set
> to EGAIN. I call select() again, with returns and says I can read
No no no. If the read does not return -1 it does not change errno. EOF isnt
an error.
-
On Thu, May 17, 2001 at 11:57:45PM +0100, Chris Evans wrote:
>
> Hi,
>
> I wonder if the following is a bug? It certainly differs from FreeBSD 4.2
> behaviour, which gives the behaviour I would expect.
>
> The following program blocks indefinitely on Linux (2.2, 2.4 not tested).
> Since the
> kernel does know that it has been 'disconnected'. One can even justify the
> inconcsistent behavior -- the write definitely has no place to go (now), but
> the read can't be totally sure that there is no possible way anybody could
> ever find the other end and write to it.
For a socket created
kernel does know that it has been 'disconnected'. One can even justify the
inconcsistent behavior -- the write definitely has no place to go (now), but
the read can't be totally sure that there is no possible way anybody could
ever find the other end and write to it.
For a socket created
On Thu, May 17, 2001 at 11:57:45PM +0100, Chris Evans wrote:
Hi,
I wonder if the following is a bug? It certainly differs from FreeBSD 4.2
behaviour, which gives the behaviour I would expect.
The following program blocks indefinitely on Linux (2.2, 2.4 not tested).
Since the other end
What I'm seeing however in an other program is that select says I
can read from the socket, and that read returns 0, with errno set
to EGAIN. I call select() again, with returns and says I can read
No no no. If the read does not return -1 it does not change errno. EOF isnt
an error.
-
To
On Fri, May 18, 2001 at 09:02:51PM +0100, Alan Cox wrote:
What I'm seeing however in an other program is that select says I
can read from the socket, and that read returns 0, with errno set
to EGAIN. I call select() again, with returns and says I can read
No no no. If the read does not
> Hmm - there's definitely a Linux inconsistency here. With SOCK_DGRAM,
> read() is blocking but write() is giving ECONNRESET.
>
> The ECONNRESET makes sense to me (despite this being a datagram socket),
> because the sockets are anonymous. Once one end goes away, the other end
> is pretty
On Thu, 17 May 2001, Alan Cox wrote:
> > The following program blocks indefinitely on Linux (2.2, 2.4 not tested).
> > Since the other end is clearly gone, I would expect some sort of error
> > condition. Indeed, FreeBSD gives ECONNRESET.
>
> Since its a datagram socket Im not convinced thats a
> The following program blocks indefinitely on Linux (2.2, 2.4 not tested).
> Since the other end is clearly gone, I would expect some sort of error
> condition. Indeed, FreeBSD gives ECONNRESET.
Since its a datagram socket Im not convinced thats a justifiable assumption.
Alan
-
To unsubscribe
Hi,
I wonder if the following is a bug? It certainly differs from FreeBSD 4.2
behaviour, which gives the behaviour I would expect.
The following program blocks indefinitely on Linux (2.2, 2.4 not tested).
Since the other end is clearly gone, I would expect some sort of error
condition. Indeed,
Hmm - there's definitely a Linux inconsistency here. With SOCK_DGRAM,
read() is blocking but write() is giving ECONNRESET.
The ECONNRESET makes sense to me (despite this being a datagram socket),
because the sockets are anonymous. Once one end goes away, the other end
is pretty useless.
Hi,
I wonder if the following is a bug? It certainly differs from FreeBSD 4.2
behaviour, which gives the behaviour I would expect.
The following program blocks indefinitely on Linux (2.2, 2.4 not tested).
Since the other end is clearly gone, I would expect some sort of error
condition. Indeed,
The following program blocks indefinitely on Linux (2.2, 2.4 not tested).
Since the other end is clearly gone, I would expect some sort of error
condition. Indeed, FreeBSD gives ECONNRESET.
Since its a datagram socket Im not convinced thats a justifiable assumption.
Alan
-
To unsubscribe
On Thu, 17 May 2001, Alan Cox wrote:
The following program blocks indefinitely on Linux (2.2, 2.4 not tested).
Since the other end is clearly gone, I would expect some sort of error
condition. Indeed, FreeBSD gives ECONNRESET.
Since its a datagram socket Im not convinced thats a
16 matches
Mail list logo
