$ ps -e -T | grep myp | grep -v grep
  797   797 ?        00:00:00 myp
  797   798 ?        00:00:00 myp
  797   799 ?        00:00:00 myp
  797   800 ?        00:00:00 myp

This shows the process myp with PID = 797 and four threads with different SPIDs.

How can I kill a particular thread of the process without killing the whole process. I understand that it might not be possible at all in some cases when there are fatal dependencies on that particular thread. But, is it possible in any case? Is yes, how?

I tried kill 799 and the process itself was terminated. Now I am not sure this was because there were dependencies that made myp fail without the process 800 or because kill is simple not able to kill individual processes.

4 Answers 4


Threads are an integral part of the process and cannot be killed outside it. There is the pthread_kill function but it only applies in the context of the thread itself. From the docs at the link:

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.

  • +1. just to add here. within the process you can use pthread_kill() to send signals to individual thread. may be you can add some signal handler which do it.
    – Hemant
    Commented Aug 23, 2010 at 13:59
  • @hemant: Suppose MS Word uses a seperate thread for spell check. Killing that thread should not bring the whole thing down, unless it is designed that way. Why cannot the process exist without that thread in situations like these?
    – Lazer
    Commented Aug 24, 2010 at 4:27
  • 1
    Well, I suppose you could design a threading model to be independent of a parent process, but allowing outside processes to kill intra-process threads but that opens up a can of worms with respect to security, process management and system integrity that I don't think any system designer would willingly submit themselves to. Threading is hard enough without those kind of headaches. Killing a thread from the inside isn't a problem because the work is done by the parent process which is held responsible if any issues arise and can be killed--automatically or otherwise.
    – gvkv
    Commented Aug 24, 2010 at 9:16
  • "unless it is designed that way": The main reason for using threads is exactly so that you can share resources. It's rather like knocking down half a house.
    – pjc50
    Commented Mar 2, 2011 at 14:55
  • 2
    @Lazer, one thread can not check spelling at the same time as another thread is updating the text because you are typing. Because of this, to have a background spell checking thread, it must do something like grab a lock to prevent the other thread from changing the text, make a copy of some of the words, release the lock, then check the copied words in the background. If you happened to kill it while it held the lock, you would hang the other thread as soon as you tried to type. Multithreaded applications are full of inter dependencies like this.
    – psusi
    Commented May 3, 2012 at 19:20

The canonical answer to this question is: With the cooperation of the process, by whatever mechanism it provides. Without the cooperation of the process, it is impossible. That the process consists of threads is an internal detail of the process that is, by intentional design, not exposed outside of the process.

  • And what about sending the other signals from the command line ?
    – yucer
    Commented Feb 15, 2018 at 14:38
  • @yucer I'm not sure I understand what you're asking. Commented Feb 15, 2018 at 17:27
  • I mean sending another signal from the list shown by "kill -l". I am looking for a way to command a particular thread to dump the stack trace in order to see what it is doing.
    – yucer
    Commented Mar 1, 2018 at 17:03
  • @yucer That's going to be platform-specific. Some do provide a way to command a particular thread to dump stack. Personally, I've found it easier just to use a script to attach a debugger (like gdb) to the process, command all the threads to dump stack, and then detach. Commented Mar 1, 2018 at 18:04

You may find tgkill() useful. It is Linux specific as the man page mentions.

tgkill() sends the signal sig to the thread with the thread ID tid in the thread group tgid. (By contrast, kill(2) can only be used to send a signal to a process (i.e., thread group) as a whole, and the signal will be delivered to an arbitrary thread within that process.)


On top of @gkv's answer you can take a look at the function pthread_cancel(3), part of <pthread.h>. From the man page:

The pthread_cancel() function sends a cancellation request to the thread thread. Whether and when the target thread reacts to the cancellation request depends on two attributes that are under the control of that thread: its cancelability state and type.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .