new server snapshot

[Brad Fitzpatrick]

Ah!  while(!exit) { ... }

I didn't see the while.  I was thinking there'd be a huge delay because
we'd exist drive_machine and then wait for some event to come back into
it.

Will apply the cosmetic patch.


On Wed, 13 Aug 2003, Anatoly Vorobey wrote:

> You wrote on Wed, Aug 13, 2003 at 11:39:37AM -0700:
> > I wanted to uncork as early as possible, right after the write, not when
> > we get back into the state machine.  Because how do we get back into the
> > drive_machine?  When some event occurs on our socket.  What event?
> > Finishing writing?  We don't want that delay.
>
> Err, no. We stay in the state machine as long as possible. After
> we write(), we break and immediately get back into the same case
> clause (since machine state didn't change, and exit flag wasn't set),
> and check whether wbytes==0. The only way we're getting out
> of the state machine is via that if(wbytes==0) (in fact, even when
> we're not getting out, we're changing states), or when one of our
> write()'s block.
>
> The delay is all of 3 CPU instructions or something.
>
> That's the general philosophy of that function: do something atomic
> and enter the state machine (via "break", which leads to the beginning
> of the loop) again, sometimes entering the same case (if you didn't
> change the state), sometimes not. Your actions inside the state
> machine don't call one another directly, they cause one another by
> changing state or other variables (like wbytes). The delay caused by
> doing a break; which immediately leads from the top-level switch
> to the same code, versus wrapping such an action in an extra loop,
> is absolutely negligible, especially considering the CPU cache, and
> the code is better designed and easier to change.
>
> The reason to move the uncorking inside the if(wbytes==0) clause is
> that this is the clause for exiting the write state. If we had, for
> some reason, dynamic response strings which could by 0 bytes long (no
> response to some command), entering the write state with wbytes==0
> would take us right to the if(wbytes==0) clause and we'd miss the
> uncorking. Since we don't actually have that situation occurring, it's
> more of a cosmetic patch (as I wrote), but this example shows why this
> is the right place for it.
>
> --
> avva
>
>