On Wed, Jul 10, 2019 at 10:45 AM Dan Eloff <dan.el...@gmail.com> wrote:
>
> On Wed, Jul 10, 2019 at 7:54 AM Michael Jones <michael.jo...@gmail.com> 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 happen, either the sender
> blocks forever because nobody read the sent value"
>
> The implications of that are that the sending and receiving code are tightly
> coupled. It is not generally safe to send on a channel without knowing how
> the receiver receives it, otherwise you can block forever like in this case
> where the receiver is using a select and the timeout wins. It's very easy to
> make your Go program leak goroutines that way - and I bet a lot of serious
> software makes that mistake in practice. In this case the sender would need
> to loop doing a non-blocking send because the receiver is using a select, and
> then handle the case where the fd didn't get sent within a reasonable time
> period (which makes no sense because no both sender and receiver have a
> timeout baked in.)
Sender would not need a loop if you use a cancel channel:
select {
case channel<-fd:
case <-cancel:
close(fd)
}
I think the problem is, as someone else already mentioned, resource
ownership. If fd cannot be sent, it still belongs to the sender, and
it has to have a way of cleaning it up. So the receiver has to let the
sender know that it is no longer interested in the resource.
>
> Basically a simple send and receive are not too bad, but once you move beyond
> that the world gets complex and fraught very quickly. Multi-threaded
> programming is hard, and Go doesn't wave that burden away. No tools that I've
> seen wave that away, so it's not really a failing of Go, it speaks more to
> the inherit complexity of the domain.
>
> --
> 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/CADz32dnDZt_npnZvCyfcGKOZ-sXHz-0V59hbhu%3DQbz5WTV3B0w%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
--
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/CAMV2Rqo2Rvu201bbr9d-9ZQxqk7-UojjHxSgzfB2yyKkabk5CA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
