Re: [go-nuts] Avoiding resource leaks with racing channels
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 wrote: > >> On Wed, Jul 10, 2019 at 7:54 AM Michael Jones >> 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.
Re: [go-nuts] Avoiding resource leaks with racing channels
On Wed, Jul 10, 2019 at 7:54 AM Michael Jones 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.
Re: [go-nuts] Avoiding resource leaks with racing channels
Maybe I'm wrong here in my understanding of unbuffered channels, but I don't think so: Matt says earlier: "Only a buffered channel can "hold" anything. If the channel is unbuffered, then you are guaranteed that another goroutine has at least received the item you sent when the send statement returns." I think at least in the simple case of `channel <- fd` this cannot be true, since that operation can only fail by panicking, and I beleive it will only panic if the channel is nil or closed. Now if you used a non-blocking send with a select, that would be a different story. So if you send over that channel it blocks the receiver wakes and runs the select but sees both channels ready picks the timeout channel at random Now one of two things must happen, either the sender blocks forever because nobody read the sent value, or the value gets lost to space and both receiver and sender continue on their merry ways. Am I wrong? -Dan -- 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%3DOm96%2B7iZet%3DDL0AaNxYVYWO6Q%3DOgvzoYiWKdZpSipHg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Avoiding resource leaks with racing channels
> > If the channel is unbuffered, there are two parties, S and R (Sender and > Receiver). If the channel is buffered, it is another party, C (channel). > The delivery chain is really S -> C -> R. Whereas in the unbuffered case, > rendezvous means an atomic exchange of the resource (S -> R). Clearly, > cleanup is the responsibility of the owner at any point in time. But the > extra owner, C, means that you will have to handle the case where the > resource is in limbo between the two systems. Since a channel cannot run > code, you will have to either let S or R handle it, or introduce a proxy, > P, who handles eventual cleanup on behalf of C. > Note in this case the channel is unbuffered, but there is no atomic exchange because of the select statement which is inherently a race between channels. If there are sends on multiple channels at close to the same time, one will randomly be chosen and the other will eventually get garbage collected with whatever was sent on it, unless you jump through hoops to avoid that situation. -- 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%3Dd23C6G%3D3W8k1-u29kHzHcorZJsYSVA%2BTx5UVcJ-J_LQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Avoiding resource leaks with racing channels
I couldn't use <-channel.Close since in my case the goroutine isn't
guaranteed to have something sent, so that would leak goroutines. I added a
cleanup goroutine to scan timed-out channels and close them, which solves
this problem. But now I can use that close as a signal to the receiver than
the a timeout happened, and eliminate the select and the race entirely. The
close can in rare cases race with the sender, but that's easily enough
fixed:
// TrySend tries to send on a possibly closed channel and handles the panic
if necessary.
// Returns true if conn was successfully sent over the channel.
func (waiter *Waiter) TrySend(conn Connection) (sent bool) {
defer func() {
r := recover()
sent = r != nil
}()
waiter.channel <- conn
return
}
So I guess the best thing to do in these cases is don't combine select with
sending unmanaged resources over a channel. It's probably worth warning
about this problem in the docs for select? It's not an obvious gotcha.
On Mon, Jul 8, 2019 at 10:06 PM Ian Lance Taylor wrote:
> On Mon, Jul 8, 2019 at 9:14 PM Daniel Eloff wrote:
> >
> > If a select statement has multiple channels ready when it runs, then it
> will choose one at a random. So if you fire something across a channel that
> holds a resource, like an open file descriptor - you have no guarantees
> that the other end of the channel receives it. The (possibly full) channel
> will get garbage collected later and the resource will leak in that case.
> >
> > Some code that explains things better than my clumsy prose:
> >
> > Receiver:
> > // Wait on the channel, or for timeout
> > select {
> > case fd := <-channel:
> > return fd, nil
> > case <-time.After(queue.timeout):
> > return nil, ErrTimeoutElapsed
> > }
> >
> > Sender:
> > channel <- fd
> >
> > What happens when the timeout races with the channel send? I think it's
> possible the select handles the timeout in that case and leaves the channel
> containing a connection alone.
> >
> > Am I right that this is a problem? How might I fix this code?
>
> There are many approaches. Here is a simple one:
>
> select {
> case fd := <-channel:
> return fd, nil
> case <-time.After(queue.timeout):
> go func() {
> <-channel.Close()
> }()
> return nil, ErrTimeoutElapsed
> }
>
> Another approach is to use a context.Context on the sending side, and
> cancel the Context if the timeout occurs. I won't write that out, but
> see https://blog.golang.org/context .
>
> Ian
>
--
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%3D%2B%3Du81%3DZLxrOvs3%3DS3%3DrP5u3ED0wsr8DFxRg7biAhwqA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
