13

enter image description here

These are the individual threads of Packet Receiver process. Is there any way to kill any individual thread? Does Linux provide any specific command which can kill or send stop signal to any particular thread under a process?

  • What is your Packet Reciever program? (I don't have it on my Debian desktop) Please tell more, perhaps provide some link. So edit your question to improve. – Basile Starynkevitch Nov 12 '17 at 7:18
  • 1
    I think you don't realize that the "stop" signal stops a process, regardless of what thread you send it to. – David Schwartz Nov 12 '17 at 18:35
  • 1
    Attach with GDB and kill the thread, then detach. – Martin Nov 12 '17 at 23:45
  • 1
    @Md.Kawsaruzzaman That just won't work. Suppose, for example, the thread is in the middle of allocating memory and holds the lock on the memory allocator. If you stop the thread, then it will never release the lock and eventually the other threads will stop too. Whatever it is you are trying to do, this is not the way to do it. (It may be that you want to stop the work that thread is doing from being done. But you need the cooperation of the process to do that. If it provides no way to do it, it can't be done.) – David Schwartz Nov 13 '17 at 18:28
  • 1
    Also note that, in your screenshot, every "thread" has a separate PID. I'm not sure you could even target separate threads, as signals could be sent to processes only. – szalski Nov 14 '17 at 14:41
17

It generally is pretty dangerous to kill an individual thread from a larger process. That thread might:

  • Be modifying some shared state with other threads that could become corrupted
  • Be holding some lock which never gets freed, causing the lock to become indefinitely unavailable
  • ...or any number of other things which might cause other threads to go wrong.

In general, outside of management and synchronisation by the application itself, killing individual threads is not something that makes sense to do.

  • 4
    This is not useful at all. OP is asking for how to kill a thread, not whether they should or not. – Martin Nov 12 '17 at 23:39
  • What i want is the process to kill or stop any particular thread for some purpose. I assume that due to some error, sometimes our receiver are getting automatically shutted down. We are finding the causes as the program is developed by our own R&D. Now the thing is there can be a possibility that some threads are automatically getting shutted down. We have tested from code side and got that child thread are independent but from server side still getting some threads down sometimes which causing total process to shut down also.. – Md. Kawsaruzzaman Nov 13 '17 at 4:00
12

You might use tgkill(2) or tkill in your C program (you'll need to use syscall(2)) but you don't want to. From inside your program you can use pthread_kill(3) - which is rarely useful.

(I don't exactly know what effect would have tgkill or tkill - e.g. with SIGKILL or SIGTERM - on a thread)

The pthreads(7) library uses low-level stuff (including some signal(7)-s and futex(7)-s etc...; see also nptl(7)) and if you raw-killed (with tkill or tgkill) some individual thread, your process would be in some wrong state (so undefined behavior) because some internal invariant would be broken.

So study the documentation of your packet receiver program and find some other way. If it is free software, study its source code and improve it.

Read more carefully signal(7) and signal-safety(7). Signals are meant to be sent to processes (by kill(2)) and handled in threads.

And in practice, signals and threads don't marry well. Read some pthread tutorial.

A common trick, when coding a multi-threaded program (and wanting to handle external signals like SIGTERM) is to use a pipe(7) to your own process and poll(2) that pipe in some other thread (you might also consider the Linux specific signalfd(2)), with a signal hander write(2)-ing a byte or a few of them into that pipe. That well known trick is well explained in Qt documentation (and you could use it in your own program, even without Qt).

  • 4
    The tgkill function provides no way to terminate a thread. It sends a signal to a thread. It is named "kill" because it is the historical way to kill a process and it cannot be used to kill a thread. – David Schwartz Nov 12 '17 at 18:34
  • I guess that sending a SIGKILL to a thread is harming it. Or is it always killing the entire process? And what about SIGTERM? BTW, even if only a thread is harmed, my point is that the process is in dire state. – Basile Starynkevitch Nov 12 '17 at 18:58
  • 5
    Yes, the SIGKILL and SIGTERM signals are defined to kill or terminate the process. That is true regardless of what thread receives them -- they still mean the same thing. Terminating a thread without the close cooperation of its process would be a crap shoot and likely catastrophic to the process. – David Schwartz Nov 12 '17 at 20:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.