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

[Mark D. Baushke]

Derek Robert Price <derek@ximbiot.com> writes:
> Mark D. Baushke wrote:
> 
> >>Subject: Re: cvs 1.11.2 buffer.c blocking socket/pipe w/bugfix
> >>To: derek@ximbiot.com (Derek Robert Price)
> >>Date: Thu, 26 Sep 2002 16:07:18 -0400 (EDT)
> >>Cc: mdb@juniper.net, peter@freebsd.org, pst@pst.org, bug-cvs@gnu.org
> >>From: lawrence.jones@eds.com (Larry Jones)
> >>
> >>Derek Robert Price writes:
> >>
> >>>Can you suggest an alternative to get around the blocking problem?
> >>>
> >>It looks to me like we're just screwed.  The problem is that when old
> >>clients use compression, they don't actually close the connection to the
> >>server until after the server closes its connection to them.  The old
> >>server didn't check for EOF on the input stream before closing it, so it
> >>didn't matter, but the new server does and thus hangs.
> >>
> >
> >Yes, that seems to be the case. However, I see have very little hope
> >that everyone will be updated to cvs 1.11.2 right away...
> >
> 
> 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.

This sounds like a promising path toward resolution.

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

That might be a useful thing to do in any case.

All I know for sure is that not having the getc() can cause hangs and
removing it can cause a cpu to loop forever, so something needs to be
done to fix this.

        Thanks,
        -- Mark