When data is received for a channel, but that channel
is not ready to receive it, the central run() loop
is currently blocked, but this can lead to deadlock
and interference between independent channels.
This CL adds an explicit buffer size to netchan
channels (an API change) - the sender will not
send values until the buffer is non empty.
The protocol changes to send ids rather than channel names
because acks can still be sent after a channel is hung up,
we we need an identifier that can be ignored.
R=r, rsc
CC=golang-dev
https://golang.org/cl/2447042
I have written a tool to verify Printf calls, and although it's not
ready to be reviewed yet it's already uncovered a spate of problems
in the repository. I'm sending this CL to break the changes into
pieces; as the tool improves it will find more, I'm sure.
R=rsc
CC=golang-dev
https://golang.org/cl/3427043
Also add exporter.Drain() to wait for completion.
This makes it possible for an Exporter to fire off a message
and wait (by calling Drain) for the message to be received,
even if a client has yet to call to retrieve it.
Once this design is settled, I'll do the same for import send.
Testing strategies welcome. I have some working stand-alone
tests.
R=rsc
CC=golang-dev
https://golang.org/cl/2137041
Two tests start a goroutine which runs exportSend, and then
the tests run importReceive. exportSend creates an export
channel. importReceive asks to receive values on that
channel. Because exportSend runs in a separate goroutine,
it's possible for the export client to receive the request for
values on the channel, from importReceive, before the
goroutine actually creates the export channel. That causes an
error: "export: no such channel: exportedSend". This patch
avoids the race by creating the export channel before starting
the goroutine.
There does not seem to be a similar race condition in the
tests which send data in the other direction.
R=r
CC=golang-dev
https://golang.org/cl/2026045
limitations:
poor error handling
teardown not done
exporter must send, importer must receive
testing is rudimentary at best
R=rsc
CC=golang-dev
https://golang.org/cl/186234
