WASI SDK 26 broke CPython (probably due to threads)

[brettcannon]

If you build CPython with WASI SDK 26, it will cause the interpreter to hang on exit. Running the test suite shows a hang on https://github.com/python/cpython/blob/7dc42b67a75f58a2b1c0a4560bd4bf8ff25cac8b/Modules/_testcapimodule.c#L1628-L1684 which is called test_pythread_tss_key_state. Since everything works in WASI SDK 25, my guess is 3f7eb4c did something.

[yamt]

If you build CPython with WASI SDK 26, it will cause the interpreter to hang on exit. Running the test suite shows a hang on https://github.com/python/cpython/blob/7dc42b67a75f58a2b1c0a4560bd4bf8ff25cac8b/Modules/_testcapimodule.c#L1628-L1684 which is called test_pythread_tss_key_state. Since everything works in WASI SDK 25, my guess is 3f7eb4c did something.

are you sure it works with WASI-SDK 25?
looking at the code it has always been broken to me.

do you mean WASI-SDK 24, which didn't provide pthread.h at all?

[brettcannon]

are you sure it works with WASI-SDK 25?

Yep, I just double-checked: py Tools/wasm/wasi build --quiet --wasi-sdk /opt/wasi-sdk-25.0-x86_64-linux -- --with-pydebug -C.

It might work with WASI SDK 25 because pthread.h was conditional then while WASI SDK 26 made it unconditional (at least based on the commit message for 3f7eb4c ). If that's the case then Python's own pthread stubs would have been used still in WASI SDK 25.

[yamt]

are you sure it works with WASI-SDK 25?

Yep, I just double-checked: py Tools/wasm/wasi build --quiet --wasi-sdk /opt/wasi-sdk-25.0-x86_64-linux -- --with-pydebug -C.

It might work with WASI SDK 25 because pthread.h was conditional then while WASI SDK 26 made it unconditional (at least based on the commit message for 3f7eb4c ). If that's the case then Python's own pthread stubs would have been used still in WASI SDK 25.

ok. thank you for confirmation.

yes, cpython's configure script sets HAVE_PTHREAD_STUBS to 1 for wasi sdk 25 as it doesn't have pthread_create.

pthread_key_destroy hang itself happens with wasi-sdk-25. (i confirmed with a simple test program to perform pthread_key_create and then pthread_key_destroy.)
#618 fixes it.