Would the Context package not work for this issue? (kinda new gopher here) 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 <javascript:>> wrote: > >> On Wed, Jul 10, 2019 at 6:45 PM Dan Eloff <dan....@gmail.com >> <javascript:>> wrote: >> >>> On Wed, Jul 10, 2019 at 7:54 AM Michael Jones <michae...@gmail.com >>> <javascript:>> 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.
