Date: Mon, 22 Mar 1999 14:26:04 -0600 (CST) From: Jonathan Lemon <jlemon@americantv.com> To: rfg@monkeys.com, freebsd-questions@freebsd.org Subject: Re: Is select(2) a liar? Message-ID: <199903222026.OAA09449@free.pcs> In-Reply-To: <local.mail.freebsd-questions/5797.922133534@monkeys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <local.mail.freebsd-questions/5797.922133534@monkeys.com> you write:
>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?
How about if it's in a closed state? A closed state isn't an error
state; an error is flagged only after attempting to write to a closed
socket.
Here's the definition of sowritable(): (from sys/sys/socketvar.h)
#define sowriteable(so) \
((sbspace(&(so)->so_snd) >= (so)->so_snd.sb_lowat && \
(((so)->so_state&SS_ISCONNECTED) || \
((so)->so_proto->pr_flags&PR_CONNREQUIRED)==0)) || \
((so)->so_state & SS_CANTSENDMORE) || \
(so)->so_error)
CANTSENDMORE is set if the socket is the process of disconnecting (or
has already disconnected).
If you're writing new code, you may want to use poll(), it's cleaner
than select() in handling these kind of things (IMHO).
--
Jonathan
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?199903222026.OAA09449>