Yeah, agreed. I've been deep into concurrent programming for a long time now, and into lock-free programming as well which is the most fraught kind of programming I've ever done. Parallel is the future, it has been that way for a long time, but it's only getting more and more obvious.
I think in this specific case, the timeout should have been handled on the sending side in a select, almost identically to the receiver code I posted. If the timer channel triggers, then close the channel to indicate to the receiver that it can wake up and it has timed out. Then the sender can go ahead and clean up the resource which it still owns. Doing it on the receiver side is fraught with problems. I solved it with a dedicated go routine that scans for timed out waiters and expires them by closing the channel, but that meant the sender now needs to handle the rare panic if it sends 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 <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/CADz32d%3Dm5fc40-1kBPdynqg6_RgmoZnMGyhccDam6FF0u8tOEA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
