runtime: main_init_done can be implemented more efficiently #15943
Comments
Ping @ianlancetaylor. Should this bump to Go1.10? |
Bumping. Sigh. |
Hi, I just bumped into this... are there possibly any updates/workarounds for this? |
@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 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 |
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. |
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 throughruntime·needm
. We can arrange forneedm
to wait for initialization to be complete. It already waits for a newM
to be created.In fact,
needm
already has a race condition. It crashes ifcgoHasExtraM
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 ifislibrary || isarchive
; we should simply wait.The text was updated successfully, but these errors were encountered: