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.) 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.
