So it is neither a bug nor a feature.
It is just that the program is not well written which makes its behavior
compiler dependent.
On Thursday, September 7, 2017 at 4:54:16 PM UTC-4, T L wrote:
>
> firstly, finalizers are never guaranteed to be run.
> secondly, there are many modifications/improvements in
> the garbage collection implementation in the official Go compiler, from
> version to version.
> The garbage collection implementation in Go 1.8 is better than Go 1.7
> so that the S object is finalized earlier than Go 1.7.
>
> On Thursday, September 7, 2017 at 12:21:33 PM UTC-4, Huafeng wrote:
>>
>> package main
>>
>> import (
>> "sync"
>> "runtime"
>> )
>>
>> type S struct {
>> chs chan int
>> }
>>
>> var wg sync.WaitGroup
>>
>> func worker(s *S) {
>> for i := range s.chs {
>> println("In worker, ch = ", i)
>> }
>>
>> wg.Done()
>> }
>>
>> func main() {
>> s := S{make(chan int)}
>>
>> runtime.SetFinalizer(&s, func(ss *S) {
>> println("Finalizer")
>> close(ss.chs)
>> })
>>
>>
>> wg.Add(1)
>>
>> go worker(&s)
>> for i := 0; i < 1; i++ {
>> s.chs <- 1
>> }
>>
>> runtime.GC()
>>
>> wg.Wait()
>> }
>>
>>
>> *Output (Go 1.8.3):*
>>
>>
>> In worker, ch = 1
>> Finalizer
>>
>>
>>
>> ---
>>
>> As my expectation, runtime.GC() will not collect `s` , because `worker`
>> still holds a reference to `s.chs`. So that the program would deadlock.
>>
>> However, this program terminates in go 1.8.3, while deadlocks in go 1.7.
>>
>> Does something change in go 1.8.3?
>>
>> I guess it has something to do with `range` and `channel`, but know
>> nothing more .
>>
>> Does anyone know what happens to this garbage collection process?
>>
>> Thanks very much for reading this.
>>
>>
>>
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
