runtime: m->procid not set when using cgo

[derekparker]

Internally, m->procid is set by the OS specific functions defined by the Go runtime such as runtime.clone on Linux. These functions are not called when using cgo, preferring instead the C version.

Would it make sense to set m->procid in the various runtime.minit functions that are OS specific? That would ensure m->procid is always set, as I assume runtime.minit will always be called for any new thread.

[minux]

why procid is needed when cgo is enabled? We don't manage those threads, so procid is definitely not needed.

[derekparker]

For debuggers, mostly - the actual runtime never cares about procid as far as I know. An M still represents an OS thread and will exist whether or not cgo is enabled, so procid should contain the correct thread ID.

[gopherbot]

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