From: Kurt Roeckx <Q@ping.be>
To: Chris Evans <chris@scary.beasts.org>
Cc: linux-kernel@vger.kernel.org, davem@redhat.com
Subject: Re: Kernel bug with UNIX sockets not detecting other end gone?
Date: Fri, 18 May 2001 19:24:22 +0200 [thread overview]
Message-ID: <20010518192422.B18162@ping.be> (raw)
In-Reply-To: <Pine.LNX.4.30.0105172353480.13175-100000@ferret.lmh.ox.ac.uk>
In-Reply-To: <Pine.LNX.4.30.0105172353480.13175-100000@ferret.lmh.ox.ac.uk>
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 is clearly gone, I would expect some sort of error
> condition. Indeed, FreeBSD gives ECONNRESET.
I'm having a simular problem, but somehow can't recreate it.
The difference is that I set the sockets to non-blocking, and
expect it to return some error.
read() returns 0, with errno set to 0, if the socket is still
open it returns -1 with errno set 11 (EAGAIN). I can understand
those behaviours.
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
from that socket ..., which keeps going on. It stops from the
moment there is any i/o on an other socket.
Is there any way you can detect the other side is gone without
using write()? write() shoud return an EPIPE. Should I be able
to detect it with read(), or some oter system call?
Kurt
next prev parent reply other threads:[~2001-05-18 17:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-17 22:57 Kernel bug with UNIX sockets not detecting other end gone? Chris Evans
2001-05-17 22:59 ` Alan Cox
2001-05-17 23:51 ` Chris Evans
2001-05-18 0:32 ` David Schwartz
2001-05-18 8:32 ` Olaf Titz
2001-05-18 17:24 ` Kurt Roeckx [this message]
2001-05-18 20:02 ` Alan Cox
2001-05-18 20:52 ` Kurt Roeckx
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010518192422.B18162@ping.be \
--to=q@ping.be \
--cc=chris@scary.beasts.org \
--cc=davem@redhat.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.