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

Clash Royale CLAN TAG#URR8PPP
up vote
13
down vote
favorite

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?
linux kill thread
 |Â
show 2 more comments
up vote
13
down vote
favorite

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?
linux kill thread
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
 |Â
show 2 more comments
up vote
13
down vote
favorite
up vote
13
down vote
favorite

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?
linux kill thread

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?
linux kill thread
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
 |Â
show 2 more comments
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
 |Â
show 2 more comments
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.
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
add a comment |Â
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).
4
Thetgkillfunction 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 aSIGKILLto a thread is harming it. Or is it always killing the entire process? And what aboutSIGTERM? 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, theSIGKILLandSIGTERMsignals 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
add a comment |Â
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.
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
add a comment |Â
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.
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
add a comment |Â
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.
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.
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
add a comment |Â
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
add a comment |Â
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).
4
Thetgkillfunction 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 aSIGKILLto a thread is harming it. Or is it always killing the entire process? And what aboutSIGTERM? 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, theSIGKILLandSIGTERMsignals 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
add a comment |Â
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).
4
Thetgkillfunction 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 aSIGKILLto a thread is harming it. Or is it always killing the entire process? And what aboutSIGTERM? 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, theSIGKILLandSIGTERMsignals 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
add a comment |Â
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).
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).
edited Nov 12 '17 at 19:55
answered Nov 12 '17 at 7:10
Basile Starynkevitch
7,9081940
7,9081940
4
Thetgkillfunction 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 aSIGKILLto a thread is harming it. Or is it always killing the entire process? And what aboutSIGTERM? 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, theSIGKILLandSIGTERMsignals 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
add a comment |Â
4
Thetgkillfunction 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 aSIGKILLto a thread is harming it. Or is it always killing the entire process? And what aboutSIGTERM? 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, theSIGKILLandSIGTERMsignals 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
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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