Description
Proposal Details
Semi-related to [#67401] because it will remove some go:linkname I used.
Previously, I coded https://github.com/folays/pprof-gls , a one-file adding some sort of pprof.Do(),
except that my version (https://github.com/folays/pprof-gls/blob/master/labels.go) add a little tweak ;
pprof.Do() allows you to (temporarily) ADD (not just REPLACE) the label-set for a given function, which will be attached by the internals to the Goroutine.
My pprof_gls.Do() (same signature) allows me to temporarily ADD (not REPLACE) additional labels to the current Goroutine label-set, EVEN IF I pass to it a nil
context.Context.
/// CONTEXT
proof uses context.Context, which hold a map[], in some special way : whilst context.Context aren't generally necessary tied to a Goroutine, regarding to pprof, Goroutines struct uses context.Context to hold the label-set, and use the context.Context general principle of map[] and copy-and-add to attach new labels to the Goroutine label-set.
When I'm not working on industrial-grade code, I sometimes don't bother to pass a context.Context around EVERYWHERE.
It means that I'm not always passing around a context.Context of a caller paths to their callees.
Sometimes, I don't even have a bug, I just want to profile CPU-bound stuff like trigonometry, octree and ray-polygon intersect stuff, and I would like to have the labels of the current area of code I'm profiling, inherit the labels of their callers, and I would also like to temporarily add some labels. (but ADD some, not just REPLACE all of them).
pprof use a "private" context.Context key, and If I remember well, also use some internals to attach the label-set to the current Goroutine struct.
In my code, ignore the //go:linkname runtime_setProfLabel runtime/pprof.runtime_setProfLabel
which is unused,
I only use two specificities :
//go:linkname runtime_getProfLabel runtime/pprof.runtime_getProfLabel
: When I didn't bothered to pass around the context.Context of callers, to get my hand on the current context holding the label-set attached to the current Goroutine.- Ugly reflectance to get around the restriction on accessing "unexported" field, to fetch a copy of the "proof" private context.Context key
// SUMMARY
My main need, which my whole code revolves around, can so be summarised as : proof.Do() is fine in itself, I just needed an API to fetch the label-set CURRENTLY APPLIED to the current Goroutine, when we didn't receive any context.Context from our callers.
// PROPOSAL
The proposal would be, instead of whitelisting usage of //go:linkname
to pprof internals, would be to either or both :
- add an API to pprof, maybe some
func GetGoroutineLabels() LabelSet
, which would returns the currently applied label-set - extend pprof.Do() like I do (when a nil context is passed, use the currently applied label-set)
- extend pprof.WithLabel() instead (in the same way)
Extending the case where a nil
context.Context is passed to pprof.Do()
/ pprof.WithLabels()
should not affect existing behaviour much, since in the current situation, passing nil
to either panics due to a nil pointer dereference.
Thanks & best regards,
Metadata
Metadata
Assignees
Type
Projects
Status
Activity
gabyhelp commentedon Aug 8, 2024
Related Issues and Documentation
proposal: runtime/pprof: add WriteGoroutineLabels function for logging #51223
pprof: add support for profiler labels #17280 (closed)
proposal: runtime/pprof: add new WithLabels* function that requires fewer allocations #33701
[Package pprof > func Do
¶
[Package pprof > func SetGoroutineLabels
¶
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
[-]proposal: add an API similar to pprof.Do(), being able to ADD labels to a coroutine, EVEN IF we don't have our hand on the current Goroutine's label-set/context[/-][+]proposal: runtime/pprof: add an API similar to pprof.Do(), being able to ADD labels to a coroutine, EVEN IF we don't have our hand on the current Goroutine's label-set/context[/+][-]proposal: runtime/pprof: add an API similar to pprof.Do(), being able to ADD labels to a coroutine, EVEN IF we don't have our hand on the current Goroutine's label-set/context[/-][+]proposal: runtime/pprof: get labels for current goroutine[/+]