cvs hanging on plan 9 at end of protocol

[Russ Cox]

I've compiled the CVS 1.11.1p1 sources on Plan 9
and am trying to debug some odd behavior when connecting
to network CVS servers.

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?

Thanks much.
Russ Cox
rsc@plan9.bell-labs.com