Not abort on pthread_create and pthread_join for single thread build

[eagleoflqj]

I've been creating patches for 3rd-party library to convert thread creation to a normal function call and remove thread join: mozc libchewing fcitx5-chinese-addons
I know the existence of real pthread support but that needs COEP and COOP. I know these 2 headers can be set by service worker, but I'm creating a JS library that can hopefully be embedded to any website, including those already have their own service worker, so single thread build is the only option for me.
It's possible to not abort on pthread_create and pthread_join, but instead, do a normal function call for create, and return 0 for join.
I've tested with code below

#include <thread>
#include <iostream>

void hello() {
    std::cout << "Hello from thread!" << std::endl;
}

int main() {
    std::thread t(hello);
    t.join();
    return 0;
}

em++ hello.cpp # The a.out.js can print normally without -pthread

This is for sure a behavior change, but I hope in a good way. Any concerns?

[sbc100]

What you are asking for sounds like some kind of pthread implementation that doesn't have any preemption. There is some precedence for this, such as GNU pth: https://www.gnu.org/software/pth/. However if you do want multiple threads without preemption you at least need to some way to switch between running threads. In gnu pth they use `setcontext` / `getcontext`. In emscripten you don't have this, but you could use something like the fibres API. However, just replacing pthread_create with a normal function call will not work for anything but the most trivial example since as soon as you have a lock that you need to wait on the whole program will deadlock. For example, if the worker thread starts while the main thread is holding lock A and the work immediately tries to acquire lock A. In short, this approach is very unlikely to work for any real world program I'm afraid. Even the GNU pth approach has some pretty serious limitation IIRC. cheers, sam

…

On Thu, Nov 6, 2025 at 2:39 PM Qijia Liu ***@***.***> wrote: *eagleoflqj* created an issue (emscripten-core/emscripten#25738) <#25738> I've been creating patches for 3rd-party library to convert thread creation to a normal function call and remove thread join: mozc <https://github.com/fcitx-contrib/fcitx5-prebuilder/blob/5d93568af8c2540bfb560b63ffac6eebf0d1ea64/patches/mozc.patch> libchewing <https://github.com/fcitx-contrib/fcitx5-prebuilder/blob/5d93568af8c2540bfb560b63ffac6eebf0d1ea64/patches/libchewing.patch#L95-L105> fcitx5-chinese-addons <https://github.com/fcitx-contrib/fcitx5-plugins/blob/master/patches/chinese-addons.patch> I know the existence of real pthread support but that needs COEP and COOP. I know these 2 headers can be set by service worker, but I'm creating a JS library that can hopefully be embedded to any website, including those already have their own service worker, so single thread build is the only option for me. It's possible to not abort on pthread_create <https://github.com/emscripten-core/emscripten/blob/5d2b2f1a59e0a1924c1c116c80019aa28ec6f37a/system/lib/pthread/library_pthread_stub.c#L95> and pthread_join <https://github.com/emscripten-core/emscripten/blob/5d2b2f1a59e0a1924c1c116c80019aa28ec6f37a/system/lib/pthread/library_pthread_stub.c#L102>, but instead, do a normal function call for create, and return 0 for join. I've tested with code below #include <thread> #include <iostream> void hello() { std::cout << "Hello from thread!" << std::endl; } int main() { std::thread t(hello); t.join(); return 0; } em++ hello.cpp # The a.out.js can print normally without -pthread This is for sure a behavior change, but I hope in a good way. Any concerns? — Reply to this email directly, view it on GitHub <#25738>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD55ZN22PA6KROID7AWSH333PE3PAVCNFSM6AAAAACLMHV6PKVHI2DSMVQWIX3LMV43ASLTON2WKOZTGU4TOOJRGY4TQMA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[eagleoflqj]

this approach is very unlikely to work for any real world program

Well, at least the examples I listed work :-) Not all programs use thread for complicated ping-pong like synchronization. For input methods that I'm porting, authors optimize for fast reaction of key stroke, so they create another thread for heavy background work like loading dictionary, or writing user input history to database etc. After the work is done, they join the thread, which is the only "synchronization".

For example, if the worker thread starts while the main thread is holding lock A and the work immediately tries to acquire lock A.

True. But this kind of synchronization doesn't work with current implementation of single thread build anyway, so direct function call won't make it worse?

[sbc100]

I think a better approach would be patch the codebases to support non-pthreaded use case.

Even the most simple threaded code normally needs to synchronize threads at some point. For example, to signal when work is done. I can't imagine many programs not doing any kind of synchronization between threads at all (i.e. no locks or atomics!). I'm not sure now many useful multithreaded programs can be written without such things.

[eagleoflqj]

I can't imagine many programs not doing any kind of synchronization between threads at all (i.e. no locks or atomics!)

I agree. If they use atomics, single thread build doesn't work at all. If they use locks, emscripten's stub functions may or may not work, determined by usages.

I'm curious about purpose of the pthread stub implementations. All other functions are no-op, and the most important pthread_create just lead to abort. Which means, for those using pthread.h to create thread, program compiles, but the binary always crashes at runtime. If asking authors to rewrite code or compile with -pthread is the purpose, it could just be an #error "To use pthread recompile with -pthread and see URL for COEP and COOP restrictions". Otherwise, basic functionality for thread execution would be a "not harmful, but best effort" impl for stub.

[sbc100]

I'm curious about purpose of the pthread stub implementations. All other functions are no-op, and the most important pthread_create just lead to abort.

I don't think that true. When pthreads are not available the stub function just fails EAGAIN, it does not abort the program:

emscripten/system/lib/pthread/library_pthread_stub.c

Lines 94 to 99 in db8daf9

	int __pthread_create(pthread_t *thread, const pthread_attr_t *attr, void *(*start_routine) (void *), void *arg) {
	return EAGAIN;
	}
	weak_alias(__pthread_create, emscripten_builtin_pthread_create);
	weak_alias(__pthread_create, pthread_create);

If you would like to experiment with your own single-thread-pthread library it should be very easy to do so because pthread_create and pthread_join stubs are weak aliases. This means that you can replace/override them simply by providing our own library. e.g. emcc -lmypthread test.c.

My contention is is that there is a vanishingly small amount of pthread-using code in the wild that will work without any thread synchronization at all. If your experiment works and you find real world codebases that can work in this way they maybe we could consider some kind of upstream feature.. but it also sounds like something that can exist outside of the core compiler.

[eagleoflqj]

This means that you can replace/override them simply by providing our own library

Makes sense! Thank you