[comp.unix.wizards] sockets and select

dhess@cs.tamu.edu (David K Hess) (02/23/90)

	This is a question for anyone who has worked heavily with
sockets.  I am working on a SparcStation1 under SunOS 4.0.3c. I am
using multiple sockets to talk back and forth between processes on
different machines (Internet domain sockets). All the sockets are
marked non-blocking (i.e.  fcntl(fd,F_SETFL, FN_DELAY)). The socket
options set are SO_KEEPALIVE and ~SO_LINGER.

	When I perform select() calls for reading only, strange
things happen. At first the call works correctly and I empty the
socket and do another select.  Then after a while, when I perform a
recv() on the "selected" socket I get 0 bytes.  Yet when I select
again I get the same socket ready for reading.  Pretty soon they are
all doing it and select() has become as useful as polling.

Has anybody run into this before? Does anybody have a fix or 
work around? Is there anything I might be doing wrong that might 
provoke this behavior?

        Any help would be appreciated.

lm@snafu.Sun.COM (Larry McVoy) (02/25/90)

In article <4309@helios.TAMU.EDU> dhess@cs.tamu.edu (David K Hess) writes:
>	When I perform select() calls for reading only, strange
>things happen. At first the call works correctly and I empty the
>socket and do another select.  Then after a while, when I perform a
>recv() on the "selected" socket I get 0 bytes.  Yet when I select
>again I get the same socket ready for reading.  Pretty soon they are
>all doing it and select() has become as useful as polling.

This sounds like you are getting EOF on the socket.  If my memory serves
me correctly, if one does a select() to see if a socket is ready for reading
and the select says "yes" but a read says "0 bytes," that means that the 
other end of the connection went away.  I could be wrong - this is based
on socket hacking I did about 4 years ago under 4.2 (4.3?) BSD on a vax.
---
What I say is my opinion.  I am not paid to speak for Sun, I'm paid to hack.
    Besides, I frequently read news when I'm drjhgunghc, err, um, drunk.
Larry McVoy, Sun Microsystems     (415) 336-7627       ...!sun!lm or lm@sun.com

natei@sco.COM (Nathaniel Ingersoll) (02/28/90)

In article <4309@helios.TAMU.EDU> dhess@cs.tamu.edu (David K Hess)
asks why select() for reading on an NDELAY socket always seems to
return a fact that the socket has data.

The manual page:
.
.     SELECT(S)		       UNIX System V		     SELECT(S)
.     ...
.     Description
.	  select examines the I/O descriptor sets whose	addresses are
.	  passed in readfds, writefds, and exceptfds to	see if some of
.	  their	descriptors are	ready for reading, are ready for
.	  writing, or have an exceptional condition pending,
.	  respectively.	 The first nfds	descriptors are	checked	in

"Ready" for reading/writing probably means that the read or the write
will filled without blocking, and since the NDELAY bit has been set,
read() will always work without blocking.

You should either
	(use NDELAY && not use select())
		||
	(use select() && not NDELAY)
-- 
________________________________________________________________________________
  I told the police that I was not injured,
  but on removing my hat, I found that I
  had a skull fracture.                     -- from an insurance accident form

penneyj@servio.UUCP (D. Jason Penney) (03/01/90)

In article <4990@scolex.sco.COM> natei@sco.com writes:
>"Ready" for reading/writing probably means that the read or the write
>will filled without blocking, and since the NDELAY bit has been set,
>read() will always work without blocking.
>
>You should either
>	(use NDELAY && not use select())
>		||
>	(use select() && not NDELAY)
>-- 

If I came across a system that did this, I would regard it as horribly
broken.  I use select() on non-blocking sockets in SunOS 4.0, Ultrix, 
Sony NEWS-OS, AIX, and other places, and on NONE of them does select() 
return a bit in readfd's unless there is at least one byte to read.

Since 0 bytes is used in both nonblocking and blocking mode to indicate
eof, if I saw that a socket was ready to read with 0 bytes left to read
in it, I would immediately close() it.

--J
-- 
D. Jason Penney           Ph: (503) 629-8383
Beaverton, OR 97006       uucp: ...uunet!servio!penneyj (penneyj@slc.com)
"Computers are useless; they can only give answers" -- Picasso