From owner-freebsd-questions Fri Mar 1 16: 7: 9 2002 Delivered-To: freebsd-questions@freebsd.org Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by hub.freebsd.org (Postfix) with SMTP id 6A3D437B400 for ; Fri, 1 Mar 2002 16:07:02 -0800 (PST) Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for hub.FreeBSD.org [216.136.204.18]) with SMTP; 2 Mar 2002 00:06:42 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA25943 for ; Fri, 1 Mar 2002 17:51:26 -0500 (EST) Received: from spirit.dynas.se (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with SMTP id g21MpbE08701 for ; Fri, 1 Mar 2002 17:51:37 -0500 (EST) Received: (qmail 26778 invoked from network); 1 Mar 2002 22:51:35 -0000 Received: from explorer.rsa.com (HELO mikko.rsa.com) (10.81.217.59) by spirit.dynas.se with SMTP; 1 Mar 2002 22:51:35 -0000 Received: (from mikko@localhost) by mikko.rsa.com (8.11.6/8.11.6) id g21MpW687462; Fri, 1 Mar 2002 14:51:32 -0800 (PST) (envelope-from mikko) Date: Fri, 1 Mar 2002 14:51:32 -0800 (PST) From: Mikko Tyolajarvi Message-Id: <200203012251.g21MpW687462@mikko.rsa.com> To: rfg@monkeys.com Cc: questions@freebsd.org Orig-To: "Ronald F. Guilmette" Subject: Re: Annoying/non-intutive/undocumented poll(2) behavior: Bug or feature? Newsgroups: local.freebsd.questions References: Your message of Thu, 28 Feb 2002 14:03:20 -0800. <20020228140039.T93443-100000@mikko.rsa.com> <75496.1014936093@monkeys.com> Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In local.freebsd.questions you write: >In message <20020228140039.T93443-100000@mikko.rsa.com>, you wrote: >> >>"Ronald F. Guilmette" : >> >>> Riddle: When is a socket error not a socket error? >>> >>> Answer: When you are using the poll(2) syscall in FreeBSD (4.3) to >>> check for the completion status of an outbound connect(2). >>> >>> I'm just about to file a formal problem {report} on this... >(I did file the problem report, by the way.) >>>... >>> Eventually, after a suitable waiting period and a suitable number of >>> retries, the attempt to connect will fail, and the call to poll(2) >>> will then return. At that point, the program checks to see if the >>> POLLERR bit is set in the returned `revents' field of the pollfd >> structure. >>>... >> >>A connect() failure is not, as the FreeBSD man page puts it, "an >>exceptional condition" nor a "device error". >The term ``exceptional condition'' is clearly one requiring interpretation. In this case (sockets on FreeBSD) it is most likely the same as for select(), which boils down to out-of-band data and nothing else. Someone involved in the brain-damage known as "winsock" obviously felt like you do: on windoze (some version of...) select() will set "exceptfds" when a connection fails. At least if I recall correctly.. or maybe when it completes... whatever. Winsuck will do a number of other strange things as well. >More to the point, it would clearly be more useful if the kernel set the >POLLERR bit in cases where an asynchronous connect attempt has failed. BTW, you _do_ know that you can wait for both readablity and writability and that the socket will become writable when the connection completes, and readable on error? The only catch is that you have to check for readablity first, as both conditions may be true. I vaguely remember some portability problems, but that does not seem to concern you :-) And it does work on FreeBSD. [ general unhappiness with the state of nonblocking connects snipped ] >It seems to me that they are more painful to deal with that they need >to be, simply because the original implementors overlooked a few minor >but important points... such as setting POLLERR and/or POLLHUP in certain >sets of very specific circumstances. >I don't believe that it is at all too late to correct those minor over- >sights. Then you have to convince the appropriate standards body. Come to think of it, I don't know is SUSv3 has anything to say on the subject. >>... and that your best >>bet on checking the status of a connect attempt is polling for >>read/write and using getsockopt() to check for error. >Umm... that's yet another kernel call. That it is. >But who's counting, right? >(Answer: I'm counting. I don't like having to make frivolous additional >context switches just because poll(2) isn't giving me the information that >it should, by all rights, be giving me in the first place.) Even if poll did set an error bit, you still would not know _what_ the error was (i.e. no errno value). And if you don't give a hoot what the problem is and if you are going to send data, just go ahead and send it -- you'll get an error immediately. Also, see above: poll for POLLIN | POLLOUT and apply appropriate logic. >>P.S. To answer your question: it is neither bug nor feature, >> it's just life :-) >Well, I disagree. I think its a bug. >At the very least, it's a non-feature... or perhaps an anti-feature... >suppression of useful information which the kernel quite clearly _does_ >already have in its possession. If you want potentially useful non-standard behaviour in FreeBSD, I don't think you should set your hopes too high on seeing it in standard interfaces. You could probably argue for connect status return values in kqueue(), though. $.02, /Mikko -- Mikko Työläjärvi_______________________________________mikko@rsasecurity.com RSA Security To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message