NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/sys/next/programm/5669

Text File | 1992-08-17 | 2.8 KB | 61 lines

Newsgroups: comp.sys.next.programmer
Path: sparky!uunet!usc!sdd.hp.com!elroy.jpl.nasa.gov!ames!agate!boulder!alumni.cs.colorado.edu!rademach
From: [e-mail] (SIMON RADEMACHER)
Subject: select() broken?
Message-ID: <[e-mail]>
Summary: does select() break after a disconnect?
Sender: [e-mail] (The Daily Planet)
Nntp-Posting-Host: alumni.cs.colorado.edu
Organization: University of Colorado, Boulder
Date: Tue, 18 Aug 1992 04:20:06 GMT
Lines: 48


Hopefully, this should be easy, but perhaps a bit dull--no graphics
nor even Objective C here.

We've developing a suite of programs here that use tcp sockets for
communications.  Select() is used to multiplex communications.  Everything
goes ok until one program disconnects from another. Then, select() in the
second program never detects any furthur events on any file descriptors,
including ones that it was detecting events on before the disconnect.
So, does select() have a bug?

Here's a more complete description of what happens with one of the programs:
1) The program opens three tcp socket services and one client. The client
   successfully connects.
2) It then does a select() in the main loop.  It uses a timeout in the
   select() so that it can do other, clock-based work.  The timeout has
   ranged from 100 microseconds to over 1 second with the same results.
3) The select() correctly identifies connection requests on the services
   as well as data arriving on the client.  When a connect request is
   seen, an accept() is done, and the new fd is added to the read fd_set.
4) Data arriving on the newly accepted fd is noted and read.
5) When one of the accepted fd's disconnects, the read fd_set shows an
   event on the fd.  A read is done resulting in EOF.  The fd is closed()
   and removed from the read fd_set.
6) From then on, the select() always waits for the duration of the time-
   out, and returns 0, eg. no events in any of the sets.

Note, the following possible causes have been checked.
a) The read fd_set IS rebuilt before each select() call.  The except fd_set
   is also built and is the same set as the read.  The write fd_set is set
   to NULL 'cause I don't care about writes.  Although the except is sent to
   select(), any exceptions are currently ignored.  (Shouldn't be a problem,
   right?)
b) The number of fds select() should look at (nfds) is larger than the
   greatest fd number.
c) The socket fd given from socket() is not closed, just the fd given by
   the accept call.

Another program behaves similarly, but includes stdin in the read fd_set
for user input.  When it looses its client connection, it also ignores
input on other inputs, including stdin.

Any clues?  Oh, BTW, this occures on 2.1 and 3.0PR2.
Thanks in advance for any help.
--
Simon Rademacher
[e-mail]