runtime: Go routine inside Go routine not exiting normally ?

[zveinn]

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version go1.8 darwin/amd64

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/anon/base/code/golang/"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/b8/3rkdjmp97bsbgsf5pn7xcwlw0000gn/T/go-build995600224=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

What did you do?

Introduced a 1 millisecond sleep timer into a goroutine before returning

https://play.golang.org/p/N5-mzj9Ywk

What did you expect to see?

Garbage collection.

What did you see instead?

No garbage collection.

Notes

There are two main functions in the go-playground exmaple..
runSpawner and runSpawner2

If you run spawner 1 before spawner 2 no garbage collection happens.
But if you reverse the order, spawner 2 child processes get garbage collected.

I don't know why this happens.. but it seems a sleep timer within a goroutine stops it ( and future processes ) from getting garbage collected ?

[davecheney]

This is working as intended. The infinite loop in your main function prevents the garbage collector from executing one phases of the gc cycle and thus gc never finishes.

…

On 25 Jun 2017, at 21:25, Sveinn Lárusson ***@***.***> wrote: Please answer these questions before submitting your issue. Thanks! What version of Go are you using (go version)? go version go1.8 darwin/amd64 What operating system and processor architecture are you using (go env)? GOARCH="amd64" GOBIN="" GOEXE="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GOOS="darwin" GOPATH="/Users/anon/base/code/golang/" GORACE="" GOROOT="/usr/local/go" GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64" GCCGO="gccgo" CC="clang" GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/b8/3rkdjmp97bsbgsf5pn7xcwlw0000gn/T/go-build995600224=/tmp/go-build -gno-record-gcc-switches -fno-common" CXX="clang++" CGO_ENABLED="1" PKG_CONFIG="pkg-config" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" What did you do? Introduced a 1 millisecond sleep timer into a goroutine before returning https://play.golang.org/p/pmScOufnFM What did you expect to see? Garbage collection. What did you see instead? No garbage collection. Notes There are two main functions in the go-playground exmaple.. runSpawner and runSpawner2 If you run spawner 1 before spawner 2 no garbage collection happens. But if you reverse the order, spawner 2 child processes get garbage collected. I don't know why this happens.. but it seems a sleep timer within a goroutine stops it ( and future processes ) from getting garbage collected ? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[zveinn]

So you are telling me that if that infinite loop would be a process serving up a websocket any goroutines spawned before that loop would never get garbage collected ?

example: https://play.golang.org/p/JFDg1oTVcE

[davecheney]

No. This is not a problem in real life, it only occurs because people tend to write for {} To prevent their main function from exiting. Don't do that, use select{} instead.

…

On 25 Jun 2017, at 22:14, Sveinn Lárusson ***@***.***> wrote: So you are telling me that if that infinite loop would be a process serving up a websocket any goroutines spawned before that loop would never get garbage collected ? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[mvdan]

Perhaps related to #10958 - that issue is about loops that don't have any blocking points or function calls, which currently interfere with GC.

[zveinn]

This code get's full memory return

https://play.golang.org/p/iJoD9YDIia

this does not

https://play.golang.org/p/U-CZ-TOWTA

It seems running goroutines within goroutines somehow does not work very well ? .. it seems the second level goroutines start stacking up and never exiting. Even if you tell them to return once finished.

Is there a reason for this :( ?

[ALTree]

No garbage collection.

How are you measuring this? This report lacks details.

This code get's full memory return

Again: how are you measuring "memory return" ? The two new examples you posted both crash and exit because they deadlock. How are you measuring memory consumption? And when? Where's the code that you use for memory consumption profiling?

[zveinn]

@ALTree I've been watching the memory consumption of the running process both from the terminal and some GUI tools.

But whats more important is that I've just been wrong this whole time.

I've been assuming things are non-blocking when they aren't and my general lack of knowledge lead me to all the wrong conclusion !

Feel free to close this issue and burn it :(

[ALTree]

No problem, thanks for checking.

As a general suggestion, if you are unsure about something it's better to bring it up as a question in one of the places we use for questions (see: Questions). The people there, then, will advise you and tell you to open an issue on the issue tracker if what you found is an actual bug.

[davecheney]

All goroutines are peers, there is no notion of a parent/child relationship. How does the second example break the garbage collector?

…

On Sun, 25 Jun 2017, 23:44 Sveinn Lárusson ***@***.***> wrote: This code get's full garbage collection https://play.golang.org/p/iJoD9YDIia this does not https://play.golang.org/p/U-CZ-TOWTA It seems running goroutines within goroutines somehow breaks GC ? .. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#20793 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcA80OZ6Voa1ikPWpsbo20yGXVFSMcks5sHmRGgaJpZM4OElOf> .