From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <0dcfc21f39f97f0b3f2a29bf97d5fc77@terzarima.net> To: 9fans@cse.psu.edu Subject: Re: [9fans] devip connect error state From: Charles Forsyth Date: Wed, 8 Aug 2007 22:48:33 +0100 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: a0b9214a-ead2-11e9-9d60-3106f5b1d025 > The result being if the connect fails, the state remains Connecting, > and subsequent writes of 'connect' commands fail because Econinuse. > > In Plan 9/Inferno, this doesn't really matter much because if dial(2) > fails we close the fd to the ctl file. > > Now in the Libra library OS stuff that I've been working on, we are > using a slight different (more socket-ish) semantic. There's nothing > in the devip man pages that say that I can't issue new commands to the > ctl file after a failed command. i imagine that on at least one of the platforms on which the code runs, ``socket-ish semantics'' are not as well-defined as you think, and the underlying fd goes into a peculiar state when the connect fails. it's not in fact hung up, but you can't connect again. i think the code's choosing an existing state (i suppose it ought to have added a new state Buggered, except that sets off the spam filters) that blocks further connection requests but allows some interaction with the fd. (i don't know why, yet.)