When I use this call to kill one thread in my process, it seems that it
killed all threads in the process. Does anyone know why? Can we just kill a
thread (by specify its tid) without affecting others?
Thanks.
Xuedong
Xuedong Chen <Xuedong.Chen@igt.com> wrote:
: When I use this call to kill one thread in my process, it seems that it
: killed all threads in the process. Does anyone know why?
If you used SIGKILL then the entire process will be terminated (since
this signal cannot be blocked). You should be able to send other signals
though to a specific thread with this routine.
Can we just kill a thread (by specify its tid) without affecting others?
Look at pthread_cancel() and the pthread_setcanceltype() (or the attr
given to pthread_create()) routines.
Xuedong Chen <Xuedong.Chen@igt.com> wrote:
When I use this call to kill one thread in my process, it seems that it
killed all threads in the process. Does anyone know why? Can we just kill a
thread (by specify its tid) without affecting others?
I’d suggest pthread_cancel() – it gives the cleanest handling of this.
pthread_abort() is much more severe. What I expect is happening with
pthread_kill() is the signal is getting delivered, not being handled,
and that thread has the PTHREAD_MULTISIG_ALLOW flag set (Posix default)
which means if an uncaught/unhandled/not-ignored signal terminates a
thread, the whole process will be terminated.
-David
QNX Training Services
dagibbs@qnx.com
David Gibbs <dagibbs@qnx.com> wrote:
: Xuedong Chen <Xuedong.Chen@igt.com> wrote:
:> When I use this call to kill one thread in my process, it seems that it
:> killed all threads in the process. Does anyone know why? Can we just kill a
:> thread (by specify its tid) without affecting others?
: I’d suggest pthread_cancel() – it gives the cleanest handling of this.
: pthread_abort() is much more severe. What I expect is happening with
: pthread_kill() is the signal is getting delivered, not being handled,
: and that thread has the PTHREAD_MULTISIG_ALLOW flag set (Posix default)
: which means if an uncaught/unhandled/not-ignored signal terminates a
: thread, the whole process will be terminated.
BTW pthread_cancel() will cancel at “cancellation point”, so if
you are sitting on a tight loop it may not do what you thing.
Cancelling a thread is never a good idea unless you can “control”
when it is cancel. For example cancelling
a thread while it is in the photon lib, is simply asking for trouble.
Photon is not cancel-safe.
–
alain
It seems that pthread_cancel () worked for me, thanks.
Xuedong
“Alain Magloire” <alain@qnx.com> wrote in message
news:9hv9tj$5nd$1@nntp.qnx.com…
David Gibbs <> dagibbs@qnx.com> > wrote:
: Xuedong Chen <> Xuedong.Chen@igt.com> > wrote:
:> When I use this call to kill one thread in my process, it seems that it
:> killed all threads in the process. Does anyone know why? Can we just
kill a
:> thread (by specify its tid) without affecting others?: I’d suggest pthread_cancel() – it gives the cleanest handling of this.
: pthread_abort() is much more severe. What I expect is happening with
: pthread_kill() is the signal is getting delivered, not being handled,
: and that thread has the PTHREAD_MULTISIG_ALLOW flag set (Posix default)
: which means if an uncaught/unhandled/not-ignored signal terminates a
: thread, the whole process will be terminated.BTW pthread_cancel() will cancel at “cancellation point”, so if
you are sitting on a tight loop it may not do what you thing.
Cancelling a thread is never a good idea unless you can “control”
when it is cancel. For example cancelling
a thread while it is in the photon lib, is simply asking for trouble.
Photon is not cancel-safe.–
alain