How to kill an individual thread under a process in linux?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
13
down vote

favorite
3












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?







share|improve this question






















  • 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














up vote
13
down vote

favorite
3












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?







share|improve this question






















  • 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












up vote
13
down vote

favorite
3









up vote
13
down vote

favorite
3






3





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?







share|improve this question














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?









share|improve this question













share|improve this question




share|improve this question








edited Nov 12 '17 at 5:43

























asked Nov 12 '17 at 5:27









Md. Kawsaruzzaman

7017




7017











  • 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
















  • 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















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





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




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




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




1




Attach with GDB and kill the thread, then detach.
– Martin
Nov 12 '17 at 23:45




Attach with GDB and kill the thread, then detach.
– Martin
Nov 12 '17 at 23:45




1




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





@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




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




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










2 Answers
2






active

oldest

votes

















up vote
18
down vote













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.






share|improve this answer
















  • 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

















up vote
12
down vote













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).






share|improve this answer


















  • 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







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f403988%2fhow-to-kill-an-individual-thread-under-a-process-in-linux%23new-answer', 'question_page');

);

Post as a guest






























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
18
down vote













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.






share|improve this answer
















  • 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














up vote
18
down vote













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.






share|improve this answer
















  • 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












up vote
18
down vote










up vote
18
down vote









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.






share|improve this answer












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.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 12 '17 at 7:26









Chris Down

75.7k11178195




75.7k11178195







  • 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












  • 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







4




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




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




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












up vote
12
down vote













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).






share|improve this answer


















  • 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















up vote
12
down vote













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).






share|improve this answer


















  • 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













up vote
12
down vote










up vote
12
down vote









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).






share|improve this answer














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).







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 12 '17 at 19:55

























answered Nov 12 '17 at 7:10









Basile Starynkevitch

7,9081940




7,9081940







  • 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













  • 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








4




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




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





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




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





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


















 

draft saved


draft discarded















































 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f403988%2fhow-to-kill-an-individual-thread-under-a-process-in-linux%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

Peggy Mitchell

Palaiologos

The Forum (Inglewood, California)