On Wed, 14 Aug 2002 16:52:08 +0200 (CEST)
Jaromir Dolecek <jdolecek@netbsd.org> wrote:

> When the other side of socket disconnects, you are supposed to get
> POLLIN from poll, and then get zero length read() == EOF. Is this
> not good enough?

For that particular project I could hack around it, but I am quite
surprised that POLLHUP event was not generated, as the general BSD sockets
API was generally followed by the UNIX domain. Not being able to know the
current connection state of the socket using select() or poll() alone has
some disadventages, especially for general event handler loops, and
threaded applications.

Installing a SIGPIPE signal handler for the whole process is not ideal for
a user-threaded application... without violating the thread API that
is. I know that better threads are to come for NetBSD eventually though,
which I am quite happy about. I would hope that kqueue interface if/when
implemented will have a unified interface for those events, independantly
of the domain type.

I have been reading about the nathan-sa branch work, and scheduler
activations paper, and have incidentally wondered: wouldn't kqueue be
capable of handling some of the required callbacks?

Matt

> Matthew Mondor wrote:
> > 
> > I recently noticed something which may or may not be of interest,
> > about not obtaining poll() POLLHUP or POLLERR event when a unix domain
> > stream client socket disconnects, using NetBSD 1.5.2 (I could not test
> > the same code on NetBSD 1.5.3 yet).
> > 
> > Is that expected behavior, and if so, how would I efficiently detect
> > disconnection events to close the fd and recycle the pollfd array
> > entry for it, as would be performed with the inet domain? Although
> > that issue mostly concerns userspace, kernel is responsible for
> > handling poll() events so I thought I would post here...
> > 
> > Thanks,
> > Matt
> >