Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!rutgers!usc!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!uiucdcs!carroll
From: carroll@cs.uiuc.edu (Alan M. Carroll)
Newsgroups: comp.unix.sysv386
Subject: accept() vs. poll()
Message-ID: <1990Dec3.004248.28763@ux1.cso.uiuc.edu>
Date: 3 Dec 90 00:42:48 GMT
Sender: news@ux1.cso.uiuc.edu (News)
Reply-To: carroll@cs.uiuc.edu (Alan M. Carroll)
Organization: Technophiles Inc. - Engineers with Attitude
Lines: 25

Setup: 386ix 2.0.2, WD 8013 ethercard.

Problem: I can't get poll() to believe that if someone's connected on a
socket, that it should tell me there is input waiting on that fd.

According to TFM, "It is possible to _select(3i)_ or _poll(2)_ a socket
for the purposes of doing an _accept_ by selecting it for read". I can't
make this work. If I run a debugger on the code, and fudge the return
values of poll() by hand, the program "works", in the sense that the
accept() succeeds, and data flows correctly. If I try setting
O_NDELAY on the accepting socket, and setting a timeout on the poll(),
accept() returns -1/EAGAIN until someone actually makes a connection,
at which time accept() returns -1/EPROTO, and I can't clear it using
either read() or setsockopt().

I've tested the code on an Intel/AT&T SysV R4 box, and it seems to work
there.

What I want to do is service the data needs of a changing set of clients,
so I have to poll() established connections and allow for new connections
to be made.
-- 
Alan M. Carroll                "It's psychosomatic. You need a lobotomy,
Epoch Development Team          I'll get a saw."
CS Grad / U of Ill @ Urbana    ...{ucbvax,pur-ee,convex}!cs.uiuc.edu!carroll