PTHREAD_KILL(3P)
π PTHREAD_KILL(3P) β ok bestie, we're in the POSIX Programmer's Manual π
Heyyy so this one lives in the POSIX Programmer's Manual, and I need you to clock something first:
β οΈ PROLOG β this manual page is part of the POSIX Programmer's Manual, so the Linux implementation of this interface may differ (bestie, go consult the corresponding Linux manual page for the details). Or honestly? It might not even be implemented on Linux at all. π
β¨ NAME β¨
pthread_kill β send a signal to a thread π―
πΈ SYNOPSIS πΈ
#include <signal.h>
int pthread_kill(pthread_t thread, int sig);
π¦ DESCRIPTION π¦
So pthread_kill() shall request that a signal be delivered to the specified thread. That's it, that's the whole vibe. π
And just like in kill(), if sig is zero, error checking shall be performed, but no signal shall actually be sent. It's giving "just checking, no notes, no signal" β¨
π RETURN VALUE π
- Successful completion? It shall return a value of zero. Slay. π
- Otherwise, it shall return an error number.
- And if
pthread_kill()fails, no signal shall be sent. Periodt. π«
π ERRORS π
pthread_kill() shall fail if:
EINVALβ the value of thesigargument is an invalid or unsupported signal number. π
Also, pthread_kill() shall not return an error code of [EINTR]. Not a thing here, bestie, don't @ me.
The following sections are informative.
π EXAMPLES π
None. β literally nothing. Iconic of them honestly.
π APPLICATION USAGE π
Okay so here's where it gets useful π«Ά β pthread_kill() gives you a mechanism for asynchronously directing a signal at a thread in the calling process. One example use case: one thread using it to affect broadcast delivery of a signal to a set of threads.
But ngl, here's the important caveat: note that pthread_kill() only causes the signal to be handled in the context of the given thread. The signal action (termination or stopping) affects the process as a whole. So the delivery is targeted, the consequences are giving main character energy for the entire process. π«
π§ RATIONALE π§
If an implementation detects use of a thread ID after the end of its lifetime, it is recommended that the function should fail and report an [ESRCH] error.
Now β existing implementations vary on the result of a pthread_kill() with a thread ID indicating an inactive thread (that's a terminated thread that has not been detached or joined). Some say success on such a call, others hand you an error of [ESRCH]. π΅π«
Since the definition of thread lifetime in this volume of POSIX.1β2017 covers inactive threads, the [ESRCH] error as described is inappropriate in this case. And in particular? This means an application cannot have one thread check for termination of another with pthread_kill(). Not the tool, bestie. Sorry. π
β FUTURE DIRECTIONS β
A future version of this standard may require that pthread_kill() not fail with [ESRCH] in the case of sending signals to an inactive thread (a terminated thread not yet detached or joined) β even though no signal will be delivered, because the thread is no longer running. π
π SEE ALSO π
kill()pthread_self()raise()
Also, from the Base Definitions volume of POSIX.1β2017: <signal.h> π
π COPYRIGHT π
Portions of this text are reprinted and reproduced in electronic form from IEEE Std 1003.1-2017, Standard for Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base Specifications Issue 7, 2018 Edition, Copyright (C) 2018 by the Institute of Electrical and Electronics Engineers, Inc and The Open Group. In the event of any discrepancy between this version and the original IEEE and The Open Group Standard, the original IEEE and The Open Group Standard is the referee document. The original Standard can be obtained online at http://www.opengroup.org/unix/online.html .
Any typographical or formatting errors that appear in this page are most likely to have been introduced during the conversion of the source files to man page format. To report such errors, see https://www.kernel.org/doc/man-pages/reporting_bugs.html .
Okay that's the whole page, we ate and left no crumbs π β¨ This edition was brought to you by IEEE/The Open Group, 2017 β mwah, love u, go read the Linux page too if you're actually on Linux π«Άππ¦
π¦ where this page comes from
- alpine 3.22: man-pages-posix 2017a-r0 Β· custom
- alpine 3.23: man-pages-posix 2017a-r0 Β· custom
- alpine 3.24: man-pages-posix 2017a-r0 Β· custom
- arch rolling: man-pages 6.19-1
- arch rolling: man-pages 6.20-1 Β· BSD-2-Clause AND BSD-3-Clause AND BSD-4.3TAHOE AND BSD-4-Clause-UC AND GPL-1.0-or-later AND GPL-2.0-only AND GPL-2.0-or-later AND GPL-3.0-or-later AND LGPL-3.0-linking-exception AND LGPL-3.0-or-later AND LicenseRef-Public-Domain AND LicenseRef-UltraPermissive AND Linux-man-pages-1-para AND Linux-man-pages-copyleft AND Linux-man-pages-copyleft-2-para AND Linux-man-pages-copyleft-var AND MIT AND Spencer-94
- nixpkgs unstable: man-pages-posix 2017a
- opensuse-leap 16.0: man-pages-posix 2017a-160000.4.1 Β· SUSE-IEEE
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms