Derek Robert Price <[EMAIL PROTECTED]> writes:
> Mark D. Baushke wrote:
>
> >>Subject: Re: cvs 1.11.2 buffer.c blocking socket/pipe w/bugfix
> >>To: [EMAIL PROTECTED] (Derek Robert Price)
> >>Date: Thu, 26 Sep 2002 16:07:18 -0400 (EDT)
> >>Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
> >>From: [EMAIL PROTECTED] (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
_______________________________________________
Bug-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-cvs
