[go-nuts] Re: Is there a memory leak on Rob Pike's demo codes?

These days one would use context.Context to cancel the 2nd and 3rd place workers. Workers would select on the send including the channel from the cancellable Context. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this

Re: [go-nuts] Re: Is there a memory leak on Rob Pike's demo codes?

To answer the original question about how to detect the leak: if you have a leak, the “goroutine” profile from runtime/pprof will show an ever-increasing number of goroutines with the same stack trace. Detecting such a leak in a unit or

Re: [go-nuts] Re: Is there a memory leak on Rob Pike's demo codes?

On Thursday, April 5, 2018 at 3:32:53 AM UTC-4, Jan Mercl wrote: > > On Thu, Apr 5, 2018 at 9:10 AM T L > wrote: > > > yes. it is a resource leak. > > It's not necessarily a leak. It's a possible leak. > > And digging even deeper: it's implementation defined. Non-reachable

Re: [go-nuts] Re: Is there a memory leak on Rob Pike's demo codes?

On Thu, Apr 5, 2018 at 9:10 AM T L wrote: > yes. it is a resource leak. It's not necessarily a leak. It's a possible leak. And digging even deeper: it's implementation defined. Non-reachable channels can be collected and goroutines blocked on them killed without changing

[go-nuts] Re: Is there a memory leak on Rob Pike's demo codes?

On Wednesday, April 4, 2018 at 11:32:10 AM UTC-4, wilby yang wrote: > > I am new to golang and I am not sure if it is a stupid question. I am > reading the slides of Rob Pike on go concurrency patterns in 2012. I > think there is a resource leak in the below function. As the function will >