> > If the channel is unbuffered, there are two parties, S and R (Sender and > Receiver). If the channel is buffered, it is another party, C (channel). > The delivery chain is really S -> C -> R. Whereas in the unbuffered case, > rendezvous means an atomic exchange of the resource (S -> R). Clearly, > cleanup is the responsibility of the owner at any point in time. But the > extra owner, C, means that you will have to handle the case where the > resource is in limbo between the two systems. Since a channel cannot run > code, you will have to either let S or R handle it, or introduce a proxy, > P, who handles eventual cleanup on behalf of C. >
Note in this case the channel is unbuffered, but there is no atomic exchange because of the select statement which is inherently a race between channels. If there are sends on multiple channels at close to the same time, one will randomly be chosen and the other will eventually get garbage collected with whatever was sent on it, unless you jump through hoops to avoid that situation. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CADz32d%3Dd23C6G%3D3W8k1-u29kHzHcorZJsYSVA%2BTx5UVcJ-J_LQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
