On Tue, Jul 9, 2019 at 6:14 AM Daniel Eloff <dan.el...@gmail.com> wrote:
> If a select statement has multiple channels ready when it runs, then it > will choose one at a random. So if you fire something across a channel that > holds a resource, like an open file descriptor - you have no guarantees > that the other end of the channel receives it. The (possibly full) channel > will get garbage collected later and the resource will leak in that case. > > To me, the real question is about "who owns the resource?" 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. I think not introducing C in the first place is the best way to go if possible. Resource handling is a place where things need to be correct before being asynchronous. -- 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/CAGrdgiVENqoANOj6xLrPYwfi_0kRXXk3zp%2B3DQO5Std6ZzKiqA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
