Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utcs!mnetor!seismo!cmcl2!philabs!nbc1!abs
From: abs@nbc1.UUCP
Newsgroups: net.unix-wizards
Subject: Undocumented behavior of select(2) with sockets in Ultrix 1.2
Message-ID: <154@nbc1.UUCP>
Date: Wed, 16-Jul-86 15:16:25 EDT
Article-I.D.: nbc1.154
Posted: Wed Jul 16 15:16:25 1986
Date-Received: Thu, 17-Jul-86 06:53:40 EDT
Distribution: net
Organization: NBC Computer Imaging, New York, NY
Lines: 37

I've encountered some undocumented behavior of select(2) that I
find useful.  I am afraid to depend on it if it is not
documented, so I wonder if anyone out in netland has encountered
this behavior and could confirm my suspicions about it.  DEC
software support has not been very helpful.

I have a server serving multiple clients, using stream sockets in
the UNIX domain.  The server waits for data to come from any of
its currently connected clients by creating a mask from the file
descriptors for these connected sockets, and calling select so
that it blocks indefinitely, thus:

		select(20,&readfds,0,0,0)

So here's the problem:  when one of these clients dies or shuts
down its end of the socket, the select in the server returns with
the bit in readfds set for the descriptor for the server's end of
that socket.  Doing an ioctl(fd,FIONREAD,&n), where fd is that
file descriptor, yields zero bytes pending on that socket!  So
there is a conflict:  select says there are bytes pending, and
ioctl says there are none.  If I do a read on that fildes, the
read returns 0 (EOF), conforming to the documented behavior of
read(2).

Since this select/ioctl conflict seems to occur only when the
socket has been closed on the other end of the connection, it
turns out to be a handy way of finding out if a socket has shut
down without having to read from, or write to, the socket.  My
hypothesis is that this is the correct (but undocumented)
behavior of select under these circumstances;  now I just need
some kind wizard(s) in netland to confirm this for me (I don't
have access to source code).

Any advice would be appreciated.  Thanks in advance.
-- 
Andrew Siegel, N2CN		NBC Computer Imaging, New York, NY
philabs!nbc1!abs		(212)664-5776