Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!chinacat!uudell!Kepler.dell.com!mjhammel From: mjhammel@Kepler.dell.com (Michael J. Hammel) Newsgroups: comp.unix.sysv386 Subject: Re: Berkley sockets Message-ID: <16730@uudell.dell.com> Date: 18 Mar 91 23:52:28 GMT References: <1991Mar14.193619.21766@m.cs.uiuc.edu> <1991Mar13.190847.9755@watdragon.waterloo.edu> <1991Mar14.122151.21216@virtech.uucp> Sender: news@uudell.dell.com Reply-To: mjhammel@Kepler.dell.com (Michael J. Hammel) Distribution: na Organization: Dell Computer Corp. Lines: 37 In article <1991Mar14.193619.21766@m.cs.uiuc.edu>, carroll@cs.uiuc.edu (Alan M. Carroll) writes: > A problem that I have had (2.0.2) with ISC is that if I have a socket > that is a passive socket, and I poll() on it, waiting for input, > poll() does _not_ return when another process connects to the socket > (neither does select()).. This means that if I want to read/write on > connected sockets _and_ listen for new connections, I lose. Hmm. Maybe I don't understand the problem, but how about doing it like this: for (;;) /* begin infinite loop waiting for new connections */ { if ( (t=accept(s, &isa, &i) ) < 0) /* hang in accept, wait for new connects*/ { ...error checking code } if ( (childpid=fork()) == 0) /* child process if fork() returns 0 */ { ...handle connection here in child process; the child inherits the socket } close(t); /* close the socket from the accept call */ } This should allow you to read/write on connected sockets in a child process and wait for more connections in the parent. You can specify how many accepts can be queued with a listen() call, I believe. This seems to work in a simple application I wrote. Michael J. Hammel | mjhammel@{Kepler|socrates}.dell.com Dell Computer Corp. | {73377.3467|76424.3024}@compuserve.com #include | zzham@ttuvm1.bitnet | uunet!uudell!feynman!mjhammel #define CUTESAYING "Recycle. Just do it."