proxying.c symbols missing when building without pthreads

[dr-matt]

I am using emscripten_proxy_promise in an application that has two variants, one built with threads enabled and one without. When building without threading, I get a link error saying emscripten_proxy_promise is undefined.

Most thread-related functions in emscripten handle non-threaded builds by using stub functions. Should the missing functions from proxying.c be added to, say, proxying_stub.c? Or is the omission intentional?

Fwiw, my current workaround is to explicitly add a stub in my code, like this:

#ifndef __EMSCRIPTEN_PTHREADS__
em_promise_t emscripten_proxy_promise(em_proxying_queue* q,
                                      pthread_t target_thread,
                                      void (*func)(void*),
                                      void* arg) {
  return em_promise_t();
}
#endif

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.65 (7f8a05dd4e37cbd7ffde6d624f91fd545f7b52e3)
clang version 20.0.0git (https:/github.com/llvm/llvm-project 547917aebd1e79a8929b53f0ddf3b5185ee4df74)
Target: wasm32-unknown-emscripten
Thread model: posix

[sbc100]

If we were going to write such as stub wouldn't we want the promise to immediately reject (i.e. error)?

I'd rather not add stub functions for symbols like this, and I think if you really need such as stub then writing one yourself like this seems like fine solution. Wouldn't it be even better to ifdef out all of the code can calls emscripten_proxy_promise instead of subbing it? In general, if you have control over the codebase I would advise using ifdef to make sure only the multi-thread build includes threading APIs like this.

[dr-matt]

@sbc100 thank you, yes a rejection from the stub would make sense, but the intention as you suggested is not to invoke the function at all, just get it to compile and coexist with non-threaded code.

The application is written in such a way that simply ifdefing out usage of the function is not straightforward. The main reason I raised this issue is that on the surface, it seems that exclusion of emscripten_proxy_promise from the stubs is inconsistent with other proxy-related code. However, I'm fine with closing this and leaving my current workaround in place if the answer is that this function doesn't belong with the other stubs by design.

[sbc100]

I think your request in reasonable. We can a stub like these ones: https://github.com/emscripten-core/emscripten/blob/9803070730e1fe8365eb44ac900c1d1751d1c2a6/src/library_async.js#L623-L625