On Wed, Jul 10, 2019 at 3:24 PM Roman Kuprov <kup...@gmail.com> wrote: > > Would the Context package not work for this issue? > (kinda new gopher here)
It is similar to using a cancel channel. Context communicates the cancellation by closing a channel returned by Done(). > > On Wednesday, July 10, 2019 at 1:08:38 PM UTC-6, Dan Eloff wrote: >> >> 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.lo...@gmail.com> wrote: >>> >>> On Wed, Jul 10, 2019 at 6:45 PM Dan Eloff <dan....@gmail.com> wrote: >>>> >>>> On Wed, Jul 10, 2019 at 7:54 AM Michael Jones <michae...@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/7a3021d7-3637-46f2-84a2-58b4b338ffa2%40googlegroups.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/CAMV2RqohgH%3DXv4VQYaxe09LRzMhkm%3DiXAOe5OS23dJR_ii_UNw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
