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

[Jason E. Aten]

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 group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

['Bryan Mills' via golang-nuts]

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 integration test, however, is fairly 
tricky: you can fairly easily detect that the goroutine count is 
increasing, but it can be tricky to figure out whether that is a leak or 
just a transient increase while the program spools up to a steady state.


On Thursday, April 5, 2018 at 4:53:21 PM UTC-4, T L wrote:
>
>
>
> 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 
>> channels can be collected and goroutines blocked on them killed without 
>> changing the semantics of the program.
>> -- 
>>
>> -j
>>
>
> There is an issue to do this, but it is denied. 
> https://github.com/golang/go/issues/19702
>  
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

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

[T L]

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 
> channels can be collected and goroutines blocked on them killed without 
> changing the semantics of the program.
> -- 
>
> -j
>

There is an issue to do this, but it is denied. 
https://github.com/golang/go/issues/19702
 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

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

[Jan Mercl]

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 the semantics of the 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.
For more options, visit https://groups.google.com/d/optout.

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

[T L]

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 
> return after the first send pair happens on channel c, the other 
> goroutines trying to send on channel c will be blocked and prevents 
> resources GC. Anyone knows golang well can confirm this? If it is resource 
> leak, how can I detect it using what kind of golang tooling?
>

yes. it is a resource leak.
 

> down votefavorite 
> 
>
> func First(query string, replicas ...Search) Result {
>   c := make(chan Result)
>   searchReplica := func(i int) {
> c <- replicas[i](query)
>   }
>   for i := range replicas {
> go searchReplica(i)
>   }
>   return <-c}
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.