[embind] Initialize embind on workers after main thread ctors.

[brendandahl]

Previously, when a statically constructed thread was created it could potentially run before all of the embind static constructors on the main thread had run. This caused the workers to miss the embind bindings.

To fix this, I've added a std::atomic so that each worker waits for embind to be ready before running the binding code.

Fixes #19849

[sbc100]

lgtm % comment

[sbc100]

Can't we just make this is __postset of some function that a core embind dependnecy? Adding this new symbol and forcing it to be included seems a more complex than it needs to be.

[kripken]

Did the priority option not work out? Either

1. Adjust the embind constructor priority to be before all user constructors. You said this might not work since it needs user stuff to run in some cases...
2. Document the issue and tell users to adjust the priority of their own constructors to be later. This seems safer to me than workers waiting on the main thread, which could deadlock IIUC?

[sbc100]

Did the priority option not work out? Either

1. Adjust the embind constructor priority to be before all user constructors. You said this might not work since it needs user stuff to run in some cases...

This doesn't work, at least last time we tried it it didn't work because there are (apparently) cases there the EMSCIRPTEN_BINDINGS block must be run after the static initializers that precede it in the same file.

Obviously we can look into those cases and see if we can change things around, but last time we tried to do this it got reverted.

2. Document the issue and tell users to adjust the priority of their own constructors to be later. This seems safer to me than workers waiting on the main thread, which could deadlock IIUC?

This doesn't work because unfortunately the default for C++ constructors is the highest possible priority so its not possible to make things to run after default C++ constructors.

[sbc100]

I think the possible deadlock risk here is very low because it would mean writing code that both creates a thread and expects to be up and running and interact-able-with all before main even runs. Doing that kind of thing in static constructors goes against most folks C/C++ sensibilities I think.

We could emit a warning in debug builds when thread end up waiting here?

[brendandahl]

Did the priority option not work out? Either

1. Adjust the embind constructor priority to be before all user constructors. You said this might not work since it needs user stuff to run in some cases...

The following is supported in embind:

const std::string global_string = "global string";

EMSCRIPTEN_BINDINGS(constants) {
  emscripten::constant("global_string", global_string);
}

Which doesn't work if we run the binding code before user's static constructors. I think this is a relatively recent change (~2yrs), so we could potentially disallow it or tell users that they need to set the priority on the global_string to be higher than the embind code.

[kripken]

I see, thanks @sbc100 @brendandahl

This PR sgtm then. Is there a way we can improve debugging here? E.g. in a debug build, perhaps show a warning when we end up waiting for that lock?

[sbc100]

I see, thanks @sbc100 @brendandahl

This PR sgtm then. Is there a way we can improve debugging here? E.g. in a debug build, perhaps show a warning when we end up waiting for that lock?

Yes that seem reasonable.