"runtime/trace"

trace.Start ?

On 29 January 2015 at 02:59, Russ Cox notifications@github.com wrote:

Dmitriy's new tracing has API entry points in runtime/pprof because all
the other runtime tracing does. But it's not consumed by pprof and probably
belongs somewhere else. Decide.

—
Reply to this email directly or view it on GitHub
#9710.

I did it looking at CPU profiling support which is essentially the same.

The design doc also mentions functions that allow to emit user marks into the trace to denote scopes of something or just one-off events (a-la TraceEvent, TraceScopeBegin, TraceScopeEnd). I've already seen two inquiries about this on golang-nuts.

So StartTrace/EndTrace + TraceEvent/TraceScopeBegin/TraceScopeEnd can make a case for runtime/trace package.

Hi Russ,

We need to decide on this asap.

People continue to ask about user-emitted events in traces. Some people also proposed some options for tracing, like disable stack collection.
We don't need to decide on all that for 1.5, I am sure we will have more trace-related functions in future, so it can make sense to move all trace-related functions to runtime/trace before the release.

https://golang.org/cl/8552 does not mention this issue but should.

Humm... I can't change that change anymore:

$ git checkout master
$ git checkout -b trace_pkg
$ git fetch https://go.googlesource.com/go refs/changes/52/8552/3 && git cherry-pick FETCH_HEAD
$ git change
git rev-parse --abbrev-ref trace_pkg@{u}
fatal: no upstream configured for branch 'trace_pkg'
git-codereview: exit status 128

@dvyukov try running git branch -u master trace_pkg after git checkout -b trace_pkg

I've mailed a new change https://go-review.googlesource.com/#/c/12511/ that just moves StartTrace/StopTrace to the new package.
8552 was more about new tracing APIs and is now cluttered with lots of unrelated stuff.

CL https://golang.org/cl/12511 mentions this issue.