I couldn't use <-channel.Close since in my case the goroutine isn't
guaranteed to have something sent, so that would leak goroutines. I added a
cleanup goroutine to scan timed-out channels and close them, which solves
this problem. But now I can use that close as a signal to the receiver than
the a
>
> 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
Maybe I'm wrong here in my understanding of unbuffered channels, but I
don't think so:
Matt says earlier: "Only a buffered channel can "hold" anything. If the
channel is unbuffered, then you are guaranteed that another goroutine has
at least received the item you sent when the send statement retur
On Wed, Jul 10, 2019 at 7:54 AM Michael Jones
wrote:
> unbuffered means nothing is sent until is is simultaneously received, so
> there is no limbo or race or uncertainty. one sender "wins" the select and
> the others remain blocked waiting.
>
So I'm correct then: "Now one of two things must hap
nds on a closed channel - not the
end of the world, but not as clean.
On Wed, Jul 10, 2019 at 10:14 AM Jesper Louis Andersen <
jesper.louis.ander...@gmail.com> wrote:
> On Wed, Jul 10, 2019 at 6:45 PM Dan Eloff wrote:
>
>> On Wed, Jul 10, 2019 at 7:54 AM Michael Jones
>> wr
