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 the sig argument 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> πŸ“š


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