Our pthread_kill implementation is incorrect, this API is not for killing threads, but sending signals to them

[sbc100]

pthread_kill, just like kill, is for sending signal to processes. What is more it seems to specifically not be capable of killing an individual pthread, only directing a signal to be received on a specific thread.

The only way a thread can be killed is if vulunarily exits, and sending a signal to a thread is just one way to ask it to exit. If one actually send SIGKILL to a thread it will bring down the entire process, not that just thread.

See https://stackoverflow.com/questions/34258271/pthread-kill-kills-not-just-a-thread-but-the-whole-program for some discussion of this.

We could make a fake implementation of pthread_kill but we would only be able to deliver signals to threads that yield in some way and not busy-looping. It seems that we can really only support cooperative receiving of signal which means we probably can't do better than pthread_cancel if we want to try to bring down a running thread.

What is more the current test for pthread_kill is currently disabled on chrome because it causes the tab to hang (i.e. worker.terminate() simply doesn't work for busy-looping threads). See:

emscripten/tests/test_browser.py

Line 3860 in 7c8be3d

@no_chrome('pthread_kill hangs chrome renderer, and keep subsequent tests from passing')

[kleisauke]

Perhaps we should only support the SIGCANCEL signal? Although deprecated by the POSIX standard, it's still used to implement pthread_cancel internally in musl, which could help move pthread_cancel to native code (see e.g. commit 16970d2).

emscripten/system/lib/libc/musl/src/thread/pthread_cancel.c

Line 110 in 0d61898

return pthread_kill(t, SIGCANCEL);

emscripten/src/library_pthread.js

Lines 761 to 763 in 0d61898

	if (signal === 33/*SIGCANCEL*/) { // Used by pthread_cancel in musl
	if (!ENVIRONMENT_IS_PTHREAD) cancelThread(thread);
	else postMessage({ 'cmd': 'cancelThread', 'thread': thread });

[sbc100]

The problem is that we have no way to deliver SIGCANCEL (or any signal) asynchronously... so we can't interrupt a busy-looping thread. But yes, one possible option is to implement pthread_kill so that it actually does call the signal handler on the respective thread (although it would have to be done in co-operations with the receiving thread). I think you are correct, I will try to do that instead.