On Wed, Jul 10, 2019 at 6:45 PM 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" > > If the sender is written as channel <- fd as you propose, then indeed, the sender will block forever. However, this is easily fixed via a select on the sender side as well with a timeout, or a context.Context that can cancel. If the send on the channel is _not_ selected, you still own the resource and have to clean up. More advanced event systems, such as Concurrent ML, has a withNACK guard for this case. If a given event is not selected, its withNACK thunk is run, allowing for cleanup. But in your case and Go, you can just have a variable or such to handle the case and clean up properly. You are right that a lot of concurrent programming is hard, especially in the presence of errors and faults. Hence, simple strategies first. And then you need to have a sketch of a proof present for more complicated interactions, or a model in TLA+ if you want it to be water-tight. However, given what AMD just launched, there is little hope for MIMD style operation now. SIMD style can still be done with a sequential but parallel program. -- J. -- 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/CAGrdgiVxOHWiz%2Bk5ga09qqnS6ndcK1dDe%2BDgnP93wHizTtquBw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
