From owner-freebsd-questions Mon Mar 22 12: 5:28 1999 Delivered-To: freebsd-questions@freebsd.org Received: from ns1.foothill.net (ns1.foothill.net [206.170.175.1]) by hub.freebsd.org (Postfix) with ESMTP id D97D314E12 for ; Mon, 22 Mar 1999 12:05:26 -0800 (PST) (envelope-from rfg@monkeys.com) Received: from monkeys.com (rfg.foothill.net [207.212.142.41]) by ns1.foothill.net (8.9.0/8.6.12) with ESMTP id LAA05153 for ; Mon, 22 Mar 1999 11:36:41 -0800 (PST) Received: from monkeys.com ([127.0.0.1]) by monkeys.com (8.9.1/8.8.5) with ESMTP id MAA05799 for ; Mon, 22 Mar 1999 12:12:14 -0800 To: questions@freebsd.org Subject: Is select(2) a liar? From: "Ronald F. Guilmette" Date: Mon, 22 Mar 1999 12:12:14 -0800 Message-ID: <5797.922133534@monkeys.com> X-Deadbolt-Note: Deadbolt(tm) Personal E-Mail Filter, Version 0.96 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Somewhere, burried deep in the bowels of the code for the utility program called strobe(1), I have seen the following code. Pay particular attention to the comment in this code. --------------------------------------------------------------------- ... timeout.tv_sec = 0; timeout.tv_usec = 50; switch (select (FD_SETSIZE, &set_sel_r, &set_sel_w, 0, &timeout)) { case -1: perror ("select"); return 0; case 0: return 1; } for (n = 0; n < a_sock_max; n++) { h = &attempt[n]; if (h->status & HT_CONNECTING) { if (FD_ISSET (h->sfd, &set_sel_r) || FD_ISSET (h->sfd, &set_sel_w)) { struct sockaddr_in in; int len = sizeof (in); /* select() lies occasionaly */ if (getpeername (h->sfd, (struct sockaddr *) &in, &len) == 0) gatherer_tcp (h); else attempt_clear (h); } } } return 1; ... --------------------------------------------------------------------- The comment in this code says that ``select() lies occasionaly'' (sp). In my own experience, it seems that this assertion may indeed be true... under FreeBSD at least. I need to understand why this might be the case, and what to do about it (in some other code I am writing). Given a stream (TCP) socket which you have started an asynchronous (non- blocking) connect for, if a call to select(2) tells you that the socket is now writable, what conditions (other than an outright rejection of the connection attempt by the peer you were connecting to) might cause a subsequent call to getpeername() to return a -1 error result? In other words, what are the precise conditions under which select() will in fact ``lie'' and say that the socket is writable when in fact it is NEITHER in a connected state nor in an error state? -- Ron Guilmette, Roseville, California ---------- E-Scrub Technologies, Inc. -- Deadbolt(tm) Personal E-Mail Filter demo: http://www.e-scrub.com/deadbolt/ -- Wpoison (web harvester poisoning) - demo: http://www.e-scrub.com/wpoison/ "Ping can be used offensively, and it's shipped with every windows CD" -- Steve Atkins To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message