Re: cvs hanging on plan 9 at end of protocol

[Ian Lance Taylor]

"Russ Cox" <rsc@plan9.bell-labs.com> writes:

> Specifically, the CVS client never hangs up.
> The problem is in the client, since
> I'm using well known servers like :pserver:cvs@vger.samba.org:/vger,
> a repository for the Linux kernel source.
> 
> I believe the problem is in get_responses_and_close,
> specifically this:
> 
>       if (! buf_empty_p (from_server)
>           || getc (from_server_fp) != EOF)
>           error (0, 0, "dying gasps from %s unexpected", 
> current_parsed_root->hostname);
>       else if (ferror (from_server_fp))
>           error (0, errno, "reading from %s", current_parsed_root->hostname);
> 
>       fclose (from_server_fp);
> 
> The client hangs in the getc() there, waiting for more
> network data.  Of course there isn't any, since the
> server thinks we're done.  So getc() blocks waiting
> for network data.  I confirmed that the CVS code
> does not try to set O_NONBLOCK on the file descriptor
> and that the server does not close the connection on
> its end (checked with tcpdump), so it seems perfectly
> reasonable to me that getc() blocks.
> 
> Unfortunately, this means we never finish, until 
> eventually the server times out and closes its connection.
> The connection closes gracefully sometimes
> when I'm compressing, but sometimes it doesn't.
> 
> I thought maybe the server output buffer wasn't
> being flushed before get_responses_and_close, but
> I flushed it (with buf_send_output(to_server) right
> before buf_shutdown(to_server)) and nothing changed.
> 
> Could someone more familiar with what's going on
> here explain to me what should be happening?
> Is my getc implementation broken (entirely likely)?
> Should the connection be opened O_NONBLOCK? 
> Something else entirely?

The client calls shutdown on the sockets which are connected to the
server.  This is shortly before the "dying gasps" code.  The server
should see this as EOF, and exit, closing the socket on its side.  The
client should see the closed socket, and getc() should return EOF.

I don't know why it is not working for you, but that is how it is
supposed to work.

Ian