[clementperon]

test_pthread_dylink_tls_free, added in #28051, is flaky on the emscripten-releases bot (test_core.cores), as reported in #28051 (comment):

Assertion failed: after < before + NUM_THREADS * 4096 / 2, at: test/core/pthread/test_pthread_dylink_tls_free.c,43,main

The test compares mallinfo() before and after 100 pthread_create/pthread_join cycles and allows 200 KiB of growth. Under PROXY_TO_PTHREAD, main() runs on a pthread, and there pthread_join() doesn't free the joined thread's own block (64 KiB stack + guard + TLS + pthread struct, about 73 KiB): _emscripten_thread_cleanup() posts CMD_CLEANUP_THREAD to the main thread, which frees it later. The next pthread_create() reaches the main thread through its mailbox rather than through that message queue, so the main thread can fall several joins behind. Three not-yet-freed blocks are enough to exceed the allowance.

This drops PROXY_TO_PTHREAD for this test. On the main runtime thread, _emscripten_thread_cleanup() calls cleanupThread() directly, so the joined thread's block is freed before pthread_join() returns and the measurement no longer depends on timing. The side-module TLS leak fixed in #28051 (about 400 KiB over 100 threads) is still caught. test_pthread_dlopen already uses dlopen plus pthread_create/pthread_join on the main thread under node in the same way.

🤖 Generated with Claude Code

https://claude.ai/code/session_01EuYUd1U1jgeJHaduQBgcKA

[gemini-code-assist]

Code Review

This pull request updates the test_pthread_dylink_tls_free test by removing the PROXY_TO_PTHREAD setting in test/test_core.py and updating the corresponding comments in test_pthread_dylink_tls_free.c. This change ensures the test runs on the main runtime thread so that pthread_join() synchronously frees the joined thread's resources, preventing timing-dependent measurement discrepancies. There are no review comments, and I have no feedback to provide.