> 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.)
