netchan.Exporter for channel to send fails after client disconnects

[gopherbot]

by greatred:

Before filing a bug, please check whether it has been fixed since
the latest release: run "hg pull -u" and retry what you did to
reproduce the problem.  Thanks.

What steps will reproduce the problem?
1. Compile server and client binaries with Go.
2. Run the server in a terminal.
3. Run the client for the first time in a different terminal.
4. Run the client for the second time.

What is the expected output?

From the server:

Received "foo"
Sent "Someone sent foo"
Received "foo"
Sent "Someone sent foo"

(server still running)

From the client runs:

$ ./client 
Got "Someone sent foo"
$ ./client 
Got "Someone sent foo"
$

(client exits immediately both times)

What do you see instead?

From the server:

$ ./server 
Received "foo"
Sent "Someone sent foo"
Received "foo"
Sent "Someone sent foo"
2011/05/11 21:55:35 netchan export: error encoding client response:write tcp
127.0.0.1:50447: broken pipe
2011/05/11 21:55:35 netchan export: sending error to client:write tcp 127.0.0.1:50447:
broken pipe

(server still running)

From the client:

$ ./client 
Got "Someone sent foo"
$ ./client

(client hanging after second run, waiting for response from channel)

Which compiler are you using (5g, 6g, 8g, gccgo)?

6g and 8g (problem reproduces on both)

Which operating system are you using?

Linux

Which revision are you using?  (hg identify)

95d2ce135523 (release-branch.r57) release/release.r57.1

Please provide any additional information below.

Attachments:

1. client.go (536 bytes)
2. server.go (499 bytes)

[rsc]

Comment 1:

Owner changed to @robpike.

Status changed to Accepted.

[gopherbot]

Comment 2 by jtdeng:

any plan to fix this problem?

[gopherbot]

Comment 3 by david.jakob.fritz:

So this is a problem in netchan/export.go:serveRecv, when an unbounded connection
(Import vs ImportNValues) is used. serveRecv is in an infinite loop when Import() is
used, and assumes that the connection never goes away. 
A solution is to check for a valid connection, and if the connection is invalid, put the
data back on the channel (for another connection to consume) and break out of the loop.
I'll think about it and get a patch submitted today or tomorrow.
For now, if you know how many channel transactions you'll be doing for a given
connection, use ImportNValues() and the problem goes away.

[gopherbot]

Comment 4 by greatred:

Putting the item back on the channel does lead to potentially altering the order of the
items queued there - although I can't think offhand of a simpler way of avoiding this.

[gopherbot]

Comment 5 by david.jakob.fritz:

Agreed. The best solution is to simultaneously check the connection status while we wait
on nch.recv(). If the connection goes away, bail from the loop, leaving anything on the
channel intact. 
Another pending netchan patch enables this as it makes nch.recv() non-blocking.

[rsc]

Comment 6:

Labels changed: added priority-later, removed priority-medium.

[rsc]

Comment 7:

netchan is deprecated.  There will be a new netchan with all new bugs.

Status changed to WontFix.