runtime: main_init_done can be implemented more efficiently

[ianlancetaylor]

A C thread in a -buildmode={c-archive,c-shared} may call back into Go code before Go initialization is complete, in which case it must wait. It currently waits using a channel called main_init_done. In the review of https://golang.org/cl/23610 Dmitry points out that this can be done more efficiently. The callback will necessarily go through runtime·needm. We can arrange for needm to wait for initialization to be complete. It already waits for a new M to be created.

In fact, needm already has a race condition. It crashes if cgoHasExtraM is not true. That global variable is set to true early in Go initialization, but that initialization will be running in a separate thread. If a C thread is fast enough in calling Go, the program will crash because Go initialization has not yet reached the required point. We should avoid crashing if islibrary || isarchive; we should simply wait.

[aclements]

Ping @ianlancetaylor. Should this bump to Go1.10?

[ianlancetaylor]

Bumping. Sigh.

[bkgs]

Hi, I just bumped into this... are there possibly any updates/workarounds for this?

[ianlancetaylor]

@bkgs What did you run into, exactly? This is mainly a performance issue. There is a theoretical bug but I don't know if it can actually occur in practice.

[bkgs]

@bkgs What did you run into, exactly? This is mainly a performance issue. There is a theoretical bug but I don't know if it can actually occur in practice.

@ianlancetaylor apologies for the lousy wording: I saw #15943 mentioned in a comment while clearing some assumptions on cgo. My question relates to the race condition in needm.

I was curious if there is a known tweak to rule this out entirely (e.g., would waiting for a Go-C call from a custom Go package init() before making C-Go calls make a difference beyond buying cgoHasExtraM init a bit more time?). It's not a big concern, we can trigger a C-Go call during startup and retry in the unlikely case of a crash.

[ianlancetaylor]

Yes, I think you can avoid the potential bug entirely by waiting for a Go -> C call, perhaps from an init function, before making any C -> Go calls.

[gopherbot]

Change https://go.dev/cl/538376 mentions this issue: runtime: implement main_init_done more efficiently