Date: Tue, 23 Mar 1999 08:10:32 -0500 (EST) From: "John W. DeBoskey" <jwd@unx.sas.com> To: jlemon@americantv.com (Jonathan Lemon) Cc: freebsd-questions@freebsd.org Subject: Re: Is select(2) a liar? Message-ID: <199903231310.IAA21363@bb01f39.unx.sas.com> In-Reply-To: From Jonathan Lemon at "Mar 22, 1999 2:26: 4 pm"
next in thread | raw e-mail | index | archive | help
Hi, I read the original mail as asking a slightly different question, which we ran into many years back... if you use idetd to spawn your server(s). Process A issues an async connect to Process B. Inetd accepts the incoming connection. Process A selects 'writable' on it's connection to Process B. Inetd fork/execs the actual Process B. a. Process B fails (for whatever reason) and exits. b. Process A issues getpeername() which fails. Depending on the performance of the different computers and the speed of the networking, the getpeername() may actually work correctly. ie: (a) & (b) above may be reversed. If the reverse is true, then the first or second read/write will fail. Good Luck, John > 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 > > ------------------------------ > 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?199903231310.IAA21363>