Cambda Zhu <cambda@xxxxxxxxxxxxxxxxx> writes: >> On Sep 23, 2022, at 15:53, Florian Weimer <fweimer@xxxxxxxxxx> wrote: >> >>> 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
