From owner-freebsd-questions Tue Mar 23 5:10:59 1999 Delivered-To: freebsd-questions@freebsd.org Received: from lamb.sas.com (lamb.sas.com [192.35.83.8]) by hub.freebsd.org (Postfix) with ESMTP id 4B1E915358 for ; Tue, 23 Mar 1999 05:10:56 -0800 (PST) (envelope-from jwd@unx.sas.com) Received: from mozart (mozart.unx.sas.com [192.58.184.8]) by lamb.sas.com (8.9.1/8.9.1) with SMTP id IAA13101; Tue, 23 Mar 1999 08:10:32 -0500 (EST) Received: from bb01f39.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA07132; Tue, 23 Mar 1999 08:10:32 -0500 Received: (from jwd@localhost) by bb01f39.unx.sas.com (8.9.1/8.9.1) id IAA21363; Tue, 23 Mar 1999 08:10:32 -0500 (EST) (envelope-from jwd) From: "John W. DeBoskey" Message-Id: <199903231310.IAA21363@bb01f39.unx.sas.com> Subject: Re: Is select(2) a liar? In-Reply-To: From Jonathan Lemon at "Mar 22, 1999 2:26: 4 pm" To: jlemon@americantv.com (Jonathan Lemon) Date: Tue, 23 Mar 1999 08:10:32 -0500 (EST) Cc: freebsd-questions@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 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