Block in dlopen until all threads have loaded the module

[sbc100]

Fixes: #18345

[dschuff]

I wonder if there is a way to test the case where multiple dlopens come from different threads before other threads are synced up. That could also happen coming from the same thread, when using the async dlopen.

[sbc100]

I wonder if there is a way to test the case where multiple dlopens come from different threads before other threads are synced up. That could also happen coming from the same thread, when using the async dlopen.

Good idea. it might be hard to setup such a test but certainly worth having. Would be good to prove that such cases don't deadlock.

[kripken]

At a high level, why do we need different syncing code for the main thread vs others? (A dlopen can appear on any thread, so I'd think the situation is symmetric?)

[sbc100]

I wonder if there is a way to test the case where multiple dlopens come from different threads before other threads are synced up. That could also happen coming from the same thread, when using the async dlopen.

Since we have single write lock that is held my dlopen, we don't allow any other thread to begin a dlopen of dlsym, whicle there is one outstange. Even async dlopen will still block until is has the write lock. We could try to relax that restriction once we take a another look at the async dlopen interface.

[sbc100]

I've updated this PR with some extra documentation in Dynamic-Linking.rst.

There are two specific issues that came up when discussed possible deadlock risks.

1. Possible deadlock due to threads calling atomics.wait directly rather than using our futex wrapper. For this case I've simply updated the docs to describe this caveat, and how to deal with it. We can look into some kind of auto-detection or re-writing solution as a followup and before we move out of the experimental.

2. Possible deadlock due to malloc taking a inner lock which might block and trigger a dlsync, which itself might trigger a TLS allocation and recurse into malloc. I've convinced myself that, at least to dlmalloc and emmalloc this won't be an issue. The deadlock that @tlively found was due to the call to malloc that removed in dylink: Remove dynamic linking startup code and allocation #18643. The only remaining allocation that can happen during dlsync is the TLS allocation here:

   emscripten/system/lib/pthread/emscripten_tls_init.c

   Line 71 in 5a2a360

   tls_block = emscripten_builtin_memalign(__builtin_wasm_tls_align(), tls_size);

   . Note that this uses emscripten_builtin_malloc which bypasses things like asan and lsan. The deadlock that thomas found was becuase lsan was taking a lock internally. The non-lsan version of malloc that we have contains only a single outer lock. This means that once that outer malloc lock is taken we don't do any blocking operations until malloc is done. We could looking into trying to detect these possible deadlocks, but I think we can leave that to as followup, especially since this deadlock issue is not introduced by this PR, since Thomas noticed it already in the tree.

[tlively]

proofreading docs

[tlively]

Suggested change

	low level primitives of `emscripten_futex_wait` and `emscirpten_yeild`.
	low level primitives of `emscripten_futex_wait` and `emscripten_yield`.

[tlively]

Suggested change

	between threads has to be done my emscripten library code. Each time a new
	between threads has to be done by emscripten library code. Each time a new

[tlively]

Suggested change

	library is loaded of a new symbol is requested via ``dlsym``, table slots can be
	library is loaded or a new symbol is requested via ``dlsym``, table slots can be

[tlively]

Suggested change

	order to make this synchronization as seamless as possible we hook into the
	order to make this synchronization as seamless as possible, we hook into the