[9fans] devip connect error state

[9fans] devip connect error state

[Eric Van Hensbergen]

So -- in devip on Inferno hosted we have this bit of code: (connectctlmsg)

       if(c->state != Idle)
                error(Econinuse);
        c->state = Connecting;
        ...
        if(waserror()){
                qlock(&c->l);
                c->state = Connected;   /* sic */
                nexterror();
        }
        /* p = x->connect(c, cb->f, cb->nf); */
        so_connect(c->sfd, ip6w(c->raddr), c->rport);
        qlock(&c->l);
        poperror();

In native inferno (and Plan 9) devip we have this bit of code:
        if(c->state != 0)
                error(Econinuse);
        c->state = Connecting;
        ...
        if(waserror()){
                qlock(c);
                nexterror();
        }
        sleep(&c->cr, connected, c);
        qlock(c);
        poperror();

------------------

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.

So, bug or feature?  At the very least it would seem a good idea to
set c->state to Hungup (and also change the c->state != 0 to a
c->state != Idle).  I have no idea why we set c->state to Connected in
Inferno hosted -- that just seems completely bonkers.

             -eric

Re: [9fans] devip connect error state

[ron minnich]

On 8/8/07, Eric Van Hensbergen <ericvh@gmail.com> wrote:

> So, bug or feature?  At the very least it would seem a good idea to
> set c->state to Hungup (and also change the c->state != 0 to a
> c->state != Idle).  I have no idea why we set c->state to Connected in
> Inferno hosted -- that just seems completely bonkers.

It actually looks like a cut and paste error -- cut, paste, forget to
change the rvalue.

ron

Re: [9fans] devip connect error state

[Charles Forsyth]

> c->state != Idle).  I have no idea why we set c->state to Connected in
> Inferno hosted -- that just seems completely bonkers.

the /* sic */ tells you that yes, it looks odd, but it's meant that way.

Re: [9fans] devip connect error state

[Eric Van Hensbergen]

On 8/8/07, Charles Forsyth <forsyth@terzarima.net> wrote:
> > c->state != Idle).  I have no idea why we set c->state to Connected in
> > Inferno hosted -- that just seems completely bonkers.
>
> the /* sic */ tells you that yes, it looks odd, but it's meant that way.
>

I kinda figured, but I was still left wondering why?

          -eric

Re: [9fans] devip connect error state

[Bruce Ellis]

c'mon eric.  "why?" when it comes to sockets has always been
swept under the carpet for all known functionality.

brucee

On 8/9/07, Eric Van Hensbergen <ericvh@gmail.com> wrote:
> On 8/8/07, Charles Forsyth <forsyth@terzarima.net> wrote:
> > > c->state != Idle).  I have no idea why we set c->state to Connected in
> > > Inferno hosted -- that just seems completely bonkers.
> >
> > the /* sic */ tells you that yes, it looks odd, but it's meant that way.
> >
>
> I kinda figured, but I was still left wondering why?
>
>          -eric
>

Re: [9fans] devip connect error state

[Charles Forsyth]

>"why?" when it comes to sockets has always been
>swept under the carpet for all known functionality.

one surprise for me is that linux locks the socket
during i/o (good), but releases it in certain cases, so
writes from several processes are interleaved every so often (bad),
so it might just as well not bother with the overall lock anyway.

Re: [9fans] devip connect error state

[Charles Forsyth]

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