From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18800 invoked by alias); 16 Jan 2014 16:47:33 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 18755 invoked by uid 48); 16 Jan 2014 16:47:30 -0000 From: "carlos at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug nptl/14744] kill -32 $pid or kill -33 $pid on a process cancels a random thread Date: Thu, 16 Jan 2014 16:47:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: minor X-Bugzilla-Who: carlos at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: 2.20 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-01/txt/msg00254.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=14744 --- Comment #6 from Carlos O'Donell --- (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.