[SDK-36] Ffmpeg freezing up when number of threads specified
Michael-F-Bryan opened this issue · comments
When number of threads are specified in the Runtime (e.g. new Runtime({poolSize: 20})) an instance of wasmer/ffmpeg freezes up and doesn't move forwards.
The leading conjecture is that FFmpeg will invoke the thread_parallelism() syscall to find out how many CPUs are available so it can spin up a number of worker threads proportional to the CPU count. The issue is our wasmer_js::tasks::ThreadPool implementation returns its capacity (i.e. max number of workers) from wasmer_wasix::VirtualTaskManager::thread_parallelism(), and because each WASIX thread is implemented as a blocking task running on the ThreadPool, if you are already running one blocking task (e.g. the WasiRunner), spawning an additional thread_pool.capacity number of blocking tasks will mean we saturate the thread pool and that last thread won't be started until one of the other blocking tasks exits. If the spawned threads depend on one another to make progress, this can introduce a deadlock.
