Plain kill probably would not, as that it not directed to a specific
thread -- any thread could dequeue it.
My immediate question when reading this was "why not use the
pthread_kill C function instead of calling the syscall directly?"
I then followed the rabbit down the hole, starting here:
https://stackoverflow.com/questions/44990839/pthread-kill-to-a-gcd-managed-thread
which lead to pthread_kill's sources, here:
https://github.com/apple/darwin-libpthread/blob/768e71947f16da454ea05c4a98f77a0f14358f21/src/pthread.c#L1412
So it's very likely we use the syscall directly instead of pthread_kill
because
we want to be able to send a signal to all kinds of threads, including
worker threads underlying GCD. I wish there was a comment to the
effect here.
I also peeked at debugserver's sources in lldb, and it seems to me that
lldb doesn't send a signal to the thread unless it was stopped on a
mach
exception?
Actually, I wonder if that syscall in gdb is really ever reached... We
shouldn't be calling darwin_resume_thread on non-resumed threads,
AFAICT,
so why do we handle that? See comment underlined below -- when isn't
the process stopped when we get there?
static void
darwin_resume_thread (struct inferior *inf, darwin_thread_t *thread,
int step, int nsignal)
{
..
switch (thread->msg_state)
{
case DARWIN_MESSAGE:
if (thread->event.ex_type == EXC_SOFTWARE
&& thread->event.ex_data[0] == EXC_SOFT_SIGNAL)
{
...
}
else if (nsignal)
{
/* Note: ptrace is allowed only if the process is stopped.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Directly send the signal to the thread. */
res = syscall (SYS___pthread_kill, thread->gdb_port, nsignal);
...
}