This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/14744] kill -32 $pid or kill -33 $pid on a process cancels a random thread
- From: "carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 16 Jan 2014 16:47:29 +0000
- Subject: [Bug nptl/14744] kill -32 $pid or kill -33 $pid on a process cancels a random thread
- Auto-submitted: auto-generated
- References: <bug-14744-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=14744
--- Comment #6 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Rich Felker from comment #5)
> Allowing cancellation from other applications is certainly not desirable,
> any moreso than it would be desirable for one process to call free() on a
> pointer malloc'd by another process. And anyway, pthread_t is only
> meaningful within the context of the process it belongs to.
>
> Technically you could use the tgkill syscall directly to intentionally send
> a cancellation signal to a particular target thread in another process (this
> would be less insane than sending it to the process and having the kernel
> randomly deliver it to one thread). Perhaps the original intent of the code
> was to allow something like this, where users might attempt to cancel a
> stuck thread as a way to get a process going again. This seems like a really
> bad idea though (most apps don't use or support cancellation, and cancelling
> a thread that's not written to be cancelled could cause dangerous
> misbehavior). If someone really wants to go to that kind of extent to try to
> "fix" a hung application, gdb is the right tool, and in fact you can use gdb
> to call pthread_cancel on a particular thread or make the thread itself call
> pthread_exit.
>
> So, I really don't think there's any sense in trying to allow cancelling
> threads from outside the process.
I agree.
--
You are receiving this mail because:
You are on the CC list for the bug.