Date: Fri, 1 Mar 2002 14:51:32 -0800 (PST) From: Mikko Tyolajarvi <mikko@dynas.se> To: rfg@monkeys.com Cc: questions@freebsd.org Subject: Re: Annoying/non-intutive/undocumented poll(2) behavior: Bug or feature? Message-ID: <200203012251.g21MpW687462@mikko.rsa.com> References: Your message of Thu, 28 Feb 2002 14:03:20 -0800. <20020228140039.T93443-100000@mikko.rsa.com> <75496.1014936093@monkeys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In local.freebsd.questions you write:
>In message <20020228140039.T93443-100000@mikko.rsa.com>, you wrote:
>>
>>"Ronald F. Guilmette" <rfg@monkeys.com>:
>>
>>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203012251.g21MpW687462>