Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

time: AfterFunc doesn't inherit parent goroutine labels #67708

Open
DmitriyMV opened this issue May 29, 2024 · 4 comments
Open

time: AfterFunc doesn't inherit parent goroutine labels #67708

DmitriyMV opened this issue May 29, 2024 · 4 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@DmitriyMV
Copy link
Contributor

DmitriyMV commented May 29, 2024

Go version

go version go1.22.3 or tip.

What did you do?

Run this code: https://go.dev/play/p/Yf7N3XhKsdF?v=gotip

What did you see happen?

goroutine profile: total 3
1 @ 0x42dcb1 0x4674fd 0x4b8a91 0x4b88c5 0x4b58eb 0x4ccf65 0x437d2b 0x46f581
# labels: {"myownlabel":"label"}
#	0x4b8a90	runtime/pprof.writeRuntimeProfile+0xb0	/usr/local/go-faketime/src/runtime/pprof/pprof.go:767
#	0x4b88c4	runtime/pprof.writeGoroutine+0x44	/usr/local/go-faketime/src/runtime/pprof/pprof.go:726
#	0x4b58ea	runtime/pprof.(*Profile).WriteTo+0x14a	/usr/local/go-faketime/src/runtime/pprof/pprof.go:368
#	0x4ccf64	main.main+0x1c4				/tmp/sandbox135271070/prog.go:24
#	0x437d2a	runtime.main+0x28a			/usr/local/go-faketime/src/runtime/proc.go:272

1 @ 0x46806e 0x46b4e5 0x4ccfbd 0x46f581
#	0x46b4e4	time.Sleep+0xe4		/usr/local/go-faketime/src/runtime/time.go:285
#	0x4ccfbc	main.main.func1+0x1c	/tmp/sandbox135271070/prog.go:18

1 @ 0x46806e 0x46b4e5 0x4ccffd 0x46f581
# labels: {"myownlabel":"label"}
#	0x46b4e4	time.Sleep+0xe4		/usr/local/go-faketime/src/runtime/time.go:285
#	0x4ccffc	main.main.func2+0x1c	/tmp/sandbox135271070/prog.go:20```

What did you expect to see?

goroutine profile: total 3
1 @ 0x42dcb1 0x4674fd 0x4b8a91 0x4b88c5 0x4b58eb 0x4ccf65 0x437d2b 0x46f581
# labels: {"myownlabel":"label"}
#	0x4b8a90	runtime/pprof.writeRuntimeProfile+0xb0	/usr/local/go-faketime/src/runtime/pprof/pprof.go:767
#	0x4b88c4	runtime/pprof.writeGoroutine+0x44	/usr/local/go-faketime/src/runtime/pprof/pprof.go:726
#	0x4b58ea	runtime/pprof.(*Profile).WriteTo+0x14a	/usr/local/go-faketime/src/runtime/pprof/pprof.go:368
#	0x4ccf64	main.main+0x1c4				/tmp/sandbox135271070/prog.go:24
#	0x437d2a	runtime.main+0x28a			/usr/local/go-faketime/src/runtime/proc.go:272

1 @ 0x46806e 0x46b4e5 0x4ccfbd 0x46f581
# labels: {"myownlabel":"label"}
#	0x46b4e4	time.Sleep+0xe4		/usr/local/go-faketime/src/runtime/time.go:285
#	0x4ccfbc	main.main.func1+0x1c	/tmp/sandbox135271070/prog.go:18

1 @ 0x46806e 0x46b4e5 0x4ccffd 0x46f581
# labels: {"myownlabel":"label"}
#	0x46b4e4	time.Sleep+0xe4		/usr/local/go-faketime/src/runtime/time.go:285
#	0x4ccffc	main.main.func2+0x1c	/tmp/sandbox135271070/prog.go:20

I think it's kinda confusing that this way you can bypass labels inheriting.

@ruyi789
Copy link

ruyi789 commented May 30, 2024

use chan

@DmitriyMV
Copy link
Contributor Author

use chan

That's creates unnecessary goroutines before we actually need them.

@AndrewHarrisSPU
Copy link

AndrewHarrisSPU commented May 30, 2024

I think it's kinda confusing that this way you can bypass labels inheriting.

Is this an honest consequence of the more complicated truth about how the runtime handles timers? Part of the story seems like it's hinted at in this detail from AfterFunc:

AfterFunc waits for the duration to elapse and then calls f in its own goroutine.

Maybe it's a bit hand-wavy to say that this is enough documentation to reach a conclusion I think is fair (that this is an honest consequence).

@mknyszek mknyszek added this to the Backlog milestone Jun 3, 2024
@mknyszek mknyszek added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jun 3, 2024
@mknyszek
Copy link
Contributor

mknyszek commented Jun 3, 2024

How do other APIs that spawn goroutines on behalf of the caller behave? Do we propagate goroutine labels to them?

I could see this being the right behavior 90% of the time, but occasionally goroutines might be created on behalf of some other goroutine with other labels, and in that case it might be misleading. I don't really know what the right behavior should be for these kinds of APIs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

4 participants