new server snapshot

[Anatoly Vorobey]

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