bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Derek Robert Price
Subject: Re: cvs 1.11.2 buffer.c blocking socket/pipe w/bugfix
Date: Thu, 24 Oct 2002 16:08:30 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0

Larry Jones wrote:

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?

Actually, at least in the case of a spurious SIGPIPE, in this case delivered via kill -15, the client ends up spitting out a bunch of file contents on STDERR with each line prefixed by `cvs checkout: warning: unrecognized response' and then both lock and hang.

Incidentally, has anyone else come across hanging servers which seem to be blocking somewhere underneath SIG_handle with sig=13? Is there any reason the server would receive a SIGPIPE which didn't come from the client? Killing child server processes with both SIGTERM and SIGKILL seems to be handled correctly.

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.

Okay. I removed the getc() from the line and it passed `make test', so I checked in a fix if anyone would like to test the new server with an old client.

The server still hangs in response to a spurious SIGPIPE, though. Not in the same location I've been seeing however, and I didn't get the garbled output on the client side this time, but that could just be timing.

Derek

--
               *8^)

Email: address@hidden

Get CVS support at <http://ximbiot.com>!
--
Funny noises are not funny.
Funny noises are not funny.
Funny noises are not funny...

         - Bart Simpson on chalkboard, _The Simpsons_







reply via email to

[Prev in Thread] Current Thread [Next in Thread]