no way for applications to detect pthread in configure time

[yamt]

a recent change moved pthread_create for wasm32-wasip1 to libc.
it broke configure-time detection of pthread like cmake FindThreads.

FindThreads internally uses CheckLibraryExists, which attempts to detect pthread_create symbol, building an equivalent of the following program.

int main(int argc, char **argv)
{
    pthread_create();
}

as it doesn't include pthread.h at all, _WASI_STRICT_PTHREAD has no chance to work it around.

[yamt]

@whitequark do you have any suggestions?

[whitequark]

How about overriring the result of the check in our CMake toolchain files?

[yamt]

How about overriring the result of the check in our CMake toolchain files?

is it possible? how?

[whitequark]

This looks like it might be difficult. I looked at FindThreads.cmake and I can't find any way to do it, except for maybe do set(Threads_FOUND OFF CACHE BOOL "Not available in wasm32-wasip1" FORCE) in the toolchain file. Do you think you can test that?

[whitequark]

But actually the situation is more complicated than this one flag can capture. What if downstream software then refuses to build because it needs <mutex> and expects it to not be available in a no-pthreads build? We need to indicate that "threads are supported but thread creation is not" which there isn't a standard way to do. This might just have to be done as a platform quirk when porting applications.

[yamt]

This looks like it might be difficult. I looked at FindThreads.cmake and I can't find any way to do it, except for maybe do set(Threads_FOUND OFF CACHE BOOL "Not available in wasm32-wasip1" FORCE) in the toolchain file. Do you think you can test that?

i tested. it didn't work.

[yamt]

But actually the situation is more complicated than this one flag can capture. What if downstream software then refuses to build because it needs <mutex> and expects it to not be available in a no-pthreads build? We need to indicate that "threads are supported but thread creation is not" which there isn't a standard way to do. This might just have to be done as a platform quirk when porting applications.

it isn't that complicated.
FindThreads finds a thread library.
a problem is we confuse it by providing a non-working thread library.
IMO, we should not provide a non-working library, at least by default.

[whitequark]

I think your only option here is a CMake patch then. I don't.

[whitequark]

a problem is we confuse it by providing a non-working thread library.
IMO, we should not provide a non-working library, at least by default.

After thinking about it I don't agree. Our thread library for the wasm32-wasi target is fully spec-compliant; it provides the threading primitives and the ability to request a thread to be spawned. There is no guarantee that this will succeed on any OS, but applications will usually asusme the call will succeed. Whether the thread library or the application is the part that is "broken" then depends on your subjective opinion and there isn't a single correct answer here.

The reason we are in this situation is that porting applications to single-threaded WASI targets was impossible: the changes required to support this target weren't accepted upstream. So the current situation is a compromise: it accommodates developers who want to assume a thread library is always present, at the cost of some inconvenience to developers who want to assume thread spawning always succeeds (at least a limited number of times).

This is a good compromise because disabling thread spawning in an application is vastly easier and less invasive than disabling the use of threading primitives. The former is very rarely accepted (and even if it is accepted it happens over objections), the latter is not questioned at all.

The PR I submitted consciously trades off one problem for another. Making FindThreads fail to find pthreads on wasm32-wasi would largely defeat its purpose, so I think I would oppose it even if you submitted a CMake patch. I think this really should be handled at application level.

[yamt]

a problem is we confuse it by providing a non-working thread library.
IMO, we should not provide a non-working library, at least by default.

After thinking about it I don't agree. Our thread library for the wasm32-wasi target is fully spec-compliant; it provides the threading primitives and the ability to request a thread to be spawned. There is no guarantee that this will succeed on any OS, but applications will usually asusme the call will succeed. Whether the thread library or the application is the part that is "broken" then depends on your subjective opinion and there isn't a single correct answer here.

i suspect it's very rare someone who uses FindThreads wants to find a "fully-compliant" stub.

The reason we are in this situation is that porting applications to single-threaded WASI targets was impossible: the changes required to support this target weren't accepted upstream. So the current situation is a compromise: it accommodates developers who want to assume a thread library is always present, at the cost of some inconvenience to developers who want to assume thread spawning always succeeds (at least a limited number of times).

This is a good compromise because disabling thread spawning in an application is vastly easier and less invasive than disabling the use of threading primitives. The former is very rarely accepted (and even if it is accepted it happens over objections), the latter is not questioned at all.

The PR I submitted consciously trades off one problem for another. Making FindThreads fail to find pthreads on wasm32-wasi would largely defeat its purpose, so I think I would oppose it even if you submitted a CMake patch. I think this really should be handled at application level.

to me, it sounds like you are just saying your applications are more important than mine.
well, maybe it's true.
what's your applications which were impossible to port?

[whitequark]

LLVM has refused to add conditional compilation for wasm32-wasi. Clang is pretty important.

[yamt]

LLVM has refused to add conditional compilation for wasm32-wasi. Clang is pretty important.

why can't you add -lwasi-emulated-pthread?

[whitequark]

That doesn't add <atomic>, and attempting to fix it at libc++ level was intractable.

[yamt]

That doesn't add <atomic>, and attempting to fix it at libc++ level was intractable.

the <atomic> header itself is available for wasm32-wasi in wasi-sdk-25.0.
it seems working.
am i missing something?

[whitequark]

Try compiling LLVM using it. Or simply placing an std::mutex, which was another contentious point in the review.