This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug nptl/14744] kill -32 $pid or kill -33 $pid on a process cancels a random thread


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]