Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

netchan: closing a channel on exported end doesn't propagate to the caller #805

Closed
gopherbot opened this issue May 23, 2010 · 11 comments
Closed

Comments

@gopherbot
Copy link
Contributor

by ghexsel:

I have a loop in the exporter sender side that sends 10 items then closes 
the netchan.  On the importer side, I have a loop to check if the channel 
is closed before trying to receive, but the channel doesn't appear to get 
closed.  Instead, I see the "2010/05/23 16:39:38 importer header: EOF" 
message (in the importer receiver side).  

A simple solution would be to change the sender side to consider EOF a 
close signal on importer.go#run().

Exporter relevant bits:

    for i := 0; i < count; i++ {
        if closed(ch) {
            fmt.Printf("Can't send, channel is closed\n")
            os.Exit(1)
        } else {
            ch <- value {23 + i, "hello"}
        }
    }
    close(ch)


Importer relevant bits:

    for {
        if closed(ch) {
            fmt.Printf("Can't receive, channel is closed\n")
            os.Exit(0)
        } else {
            v := <-ch
            fmt.Printf("%v\n", v)
        }
    }
@rsc
Copy link
Contributor

rsc commented May 24, 2010

Comment 1:

Owner changed to r...@golang.org.

Status changed to Accepted.

@robpike
Copy link
Contributor

robpike commented May 29, 2010

Comment 2:

This issue was closed by revision 752b47c.

Status changed to Fixed.

@gopherbot
Copy link
Contributor Author

Comment 3 by ghexsel:

As mentioned on issue #790, I believe that closing the channel should also flush the 
buffer prior to returning.

@gopherbot
Copy link
Contributor Author

Comment 4 by jan.newmarch:

Not fixed as at 8g version 6288 release release.2010-09-15. I get the same problem when
the client closes the channel/exits: the server reports "error decoding client header:
EOF"

@rsc
Copy link
Contributor

rsc commented Sep 17, 2010

Comment 5:

That's not the way closed works even on local channels.
http://golang.org/doc/go_spec.html#Close_and_closed
Only the *receiver* should be checking closed.

Status changed to Invalid.

@rsc
Copy link
Contributor

rsc commented Sep 17, 2010

Comment 6:

Issue #1116 has been merged into this issue.

@gopherbot
Copy link
Contributor Author

Comment 7 by jan.newmarch:

I'm checking for closed on the receiver side. When the sender process exits the receiver
gives me "error decoding client header: EOF" even though closed() returns false. I've
attached EchoClient and EchoServer. The server gives me the error.

Attachments:

  1. EchoServer.go (681 bytes)
  2. EchoClient.go (720 bytes)

@rsc
Copy link
Contributor

rsc commented Sep 17, 2010

Comment 8:

You're still not using closed right.  Please mail this to the golang-nuts
list for discussion there, so that people can find it in the archives 
later.  It's possible that the sender message is just a spurious print
though.

@gopherbot
Copy link
Contributor Author

Comment 9 by jan.newmarch:

Sorry, posting to golang-nuts is a little tricky as I am in China behind the GFC and
google groups is blocked. I've got a workaround, but it is s...l...o...w.
I'm digging into this from the bottom up now. The Go distro has test netchan_test.go.
Running as separate processes I get the behaviour documented in issue #790 of last
message not being sent and receiver hanging as it doesn't see the close from the sender.
This can be fixed by the exporter (sender) calling Drain, but then the reader sees the
closing 0 (for ints) or "" (for strings) (couldn't find the bug report I saw for this).
If the sender closes without Drain, then the reader doesn't see closed. Importer doesn't
have a Drain method so can't successfully signal closure to a reader. This requires
separate processes to demonstrate, not goroutines.
So... Importer needs a Drain method at least.

@robpike
Copy link
Contributor

robpike commented Sep 21, 2010

Comment 10:

reopening so we have a place to track this, although the original issue wasn't right.
you're right, the import side has not caught up with recent improvements to the export
side, but those are planned.

Status changed to Accepted.

@rsc
Copy link
Contributor

rsc commented Apr 20, 2011

Comment 11:

This is now part of the netchan tests.

Status changed to Fixed.

This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants