Add ability to make PTHREAD_POOL_SIZE a hard limit

[VirtualTim]

In my experience it's easy to cause a deadlock if the main threaded spawns a thread then immediately waits on it.
Untested, but something simple like this will probably cause the browser to hang if compiled with PTHREAD_POOL_SIZE=0:

main() {
  std::future<int> futureInt( std::async([&]{
      return print("test");
  }) );
  int returnValue = futureInt.get();
}

This is because the browser has to create a worker on the main thread, but is waiting on the main thread inside the get().

I'm not the only one to run into this issue (eg: #8078). I'm sure there's many other hangs logged that are caused by the same issue.

I think the easiest fix would be a another flag to make PTHREAD_POOL_SIZE a hard limit, and trying to create more threads will fail. Maybe PTHREAD_CLAMP_POOL_SIZE?

If that's not acceptable, perhaps something could be exposed on the native side that returns the number of free workers. Something equivalent to:

int GetNumberOfAvailableWorkers() {
  return EM_ASM_INT({
    return PThread.unusedWorkerPool.length;
  });
}

Anyone have any thoughts on this?

[sbc100]

Yes, many people seem to run into this issue. It seems like the problem stems from "blocking" on the main thread when there is a "not-yet-running" thread.

I believe that block on the main thread is already handled in the special way.. since it has to busy wait because the blocking primities are not allowed on the main thread.

So how about this solution:

1. Keep track treads that are "not-yet-running". i.e. threads that were started in this turn of the event loop but have not yet had their workers start.
2. Before busy-looping the main thread, error out if there are any such "not-yet-running" threads.

[sbc100]

I guess this could lead to false positives if code exists on the main that starts a new thread and then blocks on something from another thread in the same turn of the event loop?

[juj]

Main thread waiting to join a thread that has not yet started is only one scenario where this kind of deadlock can occur. There are at least two other deadlock categories/scenarios, such as thread calling a web API (e.g. IndexedDB, XHR, Fetch) that needs to internally obtain some implementation defined lock that is held by the main browser thread while it is running; or another cause is a priority inversion on held mutexes.

The issue can also occur with waiting to obtain a lock/resource/result from a thread that has not started yet, and not just waiting to join a thread that has not started yet. (But detecting what that lock/resource/result is is equivalent to halting problem)

The original approach to help debug these in general manner is the --threadprofiler flag, which shows what each thread is doing, although that feature has been left a bit scarce. The issue is that in order to reliably detect all deadlock categories above, one would have to annotate all atomic waits and spinlock waits, which can cause a large amount of performance slowdown - hence the approach was to use a special link time profiling flag.

The -s PTHREAD_POOL_SIZE=x feature was a stopgap to avoid the issues specifically due to threads not being able to start, but ultimately -s PROXY_TO_PTHREAD=1 feature is the general solution to avoid all these kinds of deadlock issues, relieving main thread to freely operate any events that the page might need to process.

If you want to add a lightweight check for "is thread yet even running?" to pthread_join, that sounds good - perhaps that'll grab the most common scenario that people are running into, and the common occurrence warrants adding a special check for that case alone.

[VirtualTim]

Last I checked PROXY_TO_PTHREAD didn't work with NO_EXIT_RUNTIME, which would kill that feature for a lot of people.

Perhaps another good idea would be to change _emscripten_main_thread_process_queued_calls to be able to spawn threads, but I don't know if that's actually possible.

[juj]

Last I checked PROXY_TO_PTHREAD didn't work with NO_EXIT_RUNTIME, which would kill that feature for a lot of people.

PROXY_TO_PTHREAD implies NO_EXIT_RUNTIME, since otherwise the runtime would shut down immediately at program startup. In pthreads, one currently needs to use something like EM_ASM(Module['noExitRuntime'] = true); to make the pthread not exit when it reaches end of its main. I think we had a conversation/issue about formalizing/unifying the model for pthreads and main browser thread, but that did not progress iirc.

Perhaps another good idea would be to change _emscripten_main_thread_process_queued_calls to be able to spawn threads, but I don't know if that's actually possible.

That function does already spawn threads, if such spawn actions are present in the proxy queue. That is, if a pthread asks to spawn a thread, it will not create a nested Worker to itself, but it will proxy the thread creation to main browser thread, which can get processed in _emscripten_main_thread_process_queued_calls of the main browser thread. However that cannot escape the fact that a Worker may only spawn up after main browser thread yields execution back to the browser itself. (that fact is an unspecced implementation detail in the Worker specification, a fact that has been unobservable until Atomics+SAB came into play)

[Y0QIN]

I meet a related probelem.
At first time , my project is used -s PTHREAD_POOL_SIZE=x and it occur deadlock.
Then I try to use PROXY_TO_PTHREAD and it error by ReferenceError: wasmAlready is not defined.
wasmAlready is a function I defined in js and use in C main()

`int main()
{ 
    printf("########FFmpeg library import complete#########\n");
    EM_ASM(wasmAlready());
    memset(&g_context, 0, sizeof(struct _ffmpeg_context_t) * MAX_CHAN_NUM);
    emscripten_exit_with_live_runtime();
    return 0;
}`

[sbc100]

I believe this issue is fixed by #9579. With that change the main thread is not blockable by default.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.