sys_tgkill(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– sys_tgkill(9) β€” like, the thread-targeted signal syscall, bestie πŸ’–

okay so this is a page from the Kernel API Manual, and it's all about sys_tgkill β€” the syscall that slides into one specific thread's DMs with a signal 🎯✨


🌸 NAME 🌸

sys_tgkill β€” send a signal to one specific thread, not the whole group, no cap πŸ’…


✨ SYNOPSIS ✨

long sys_tgkill (pid_t tgid , pid_t pid , int sig );

literally three args, that's it, that's the whole vibe 🫢


πŸŽ€ ARGUMENTS πŸŽ€

  • tgid β€” the thread group ID of the thread πŸ‘‘ (yes it wants the group too, we'll get to why)
  • pid β€” the PID of the thread πŸ¦‹ the specific one, the main character
  • sig β€” the signal to be sent πŸ”₯ the actual message

πŸ’œ DESCRIPTION πŸ’œ

so here's the iconic part: this syscall also checks the tgid, and it returns -ESRCH even if the PID exists β€” but that PID isn't belonging to the target process anymore. 😭

and like… that's not a bug, that's the whole point. it solves the problem of threads exiting and PIDs getting reused. because bestie, PIDs get recycled constantly and if you weren't double-checking you'd be out here firing signals at some totally random new process that just happened to inherit the number πŸ’€πŸ™ˆ

no cap, the tgid check is the safety rail here. it's giving "confirm before you send" energy and honestly? we stan a defensive syscall 🧚

πŸ¦‹ SEE ALSO πŸ¦‹

the kernel file ./kernel/signal.c β€” go read it, it's where all of this lives πŸ“‚

and then the whole friend group, in the order the original rolls with:

like, that's the whole signal-handling squad right there, iykyk 🌈⭐


aaaaand that's the page!! πŸ’– this one's from ./kernel, dated October 2026, and it's sys_tgkill(9) β€” mwah, go send a signal to exactly one thread and be normal about it πŸ˜ŒπŸ’…πŸŽ€

πŸ“¦ where this page comes from