Re: Syscall kill() can send signal to thread ID

Cambda Zhu [off-list ref] writes:

quoted

On Sep 23, 2022, at 15:53, Florian Weimer [off-list ref] wrote:

quoted

I don't quite understand what you mean, sorry. But if kill() returns
-ESRCH for tid which is not equal to tgid, kill() can only send signal
to thread group via main thread id, that is what BSD did and manual
said. It seems not odd?

It's still odd because there's one TID per process that's valid for
kill by accident.  That's all.

As far as I know, there is no rule forbidding 'process ID'(TGID on Linux)
equals to main thread ID, is it right?

There is an unfortunate guarantee that glibc depends upon that after
exec TGID == TID for the initial thread in a process.  I say unfortunate
because maintaining that guarantee when another thread in the process
calls exec is a bit painful.

If one wants to send signal to a specific thread, tgkill() can do
that. As far as I understand, the difference between kill() and
tgkill() is whether the signal is set on shared_pending, whatever the
ID is a process ID or a thread ID. For Linux, the main thread ID just
equals to the process ID.

Correct.  kill and tgkill uses different signal queues.  Kill is global
to the destination process and tgkill is always thread local.

So the meaning of kill(main_tid, sig) is sending signal to a process,
of which the PID equals to the first argument. It's not odd, I think.

Yes, the oddity is the TGID and TID share the same value, nothing else.

Eric