Re: cvs 1.11.2 buffer.c blocking socket/pipe w/bugfix

[Larry Jones]

Derek Robert Price writes:
> 
> The CVS protocol is set up so that the CVS client and server exchange a 
> list of supported-requests.  What if, and I'll have to review the 
> protocol to figure out exactly which request this should be done with, 
> but what if one of the requests that is sent every time has its name 
> changed.  Or better yet, clients version 1.11.2 and later send a new 
> protocol string that says "I'll close compressed connections".  Then the 
> server can use the old method when it doesn't recieve that command and 
> the new when it does.

I really don't like that idea.  This doesn't seem like the kind of thing
we need to amend the client/server protocol to address -- the benefits
of checking for stray trailing data from the client are so small that,
on further reflection, I don't think we're giving up enough to make it
worth worrying about.  It also strikes me as a bit presumptious of the
buffering library to take it upon itself to comment on how it's being
used; if the caller decides to shut down an input buffer prematurely,
what gives the buffering library the right to complain about it?

In fact, I wonder if that works at all -- if the server shuts down
prematurely (due to receiving a signal, for example) while receiving
input from a compressed connection, does its buffer shutdown wait for
the client to shut down?  Does the client necessarily get notified that
all is lost so it even knows to shut down?

> Alternatively, there must be a way to install a 30 second timeout or 
> something around that call to getc().

That's actually quite difficult to do portably, particularly since stdio
is involved in the process.

-Larry Jones

See if we can sell Mom and Dad into slavery for a star cruiser. -- Calvin