From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16368 invoked by alias); 20 Jul 2014 18:41:26 -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 15801 invoked by uid 48); 20 Jul 2014 18:41:16 -0000 From: "bugdal at aerifal dot cx" To: glibc-bugs@sourceware.org Subject: [Bug nptl/12683] Race conditions in pthread cancellation Date: Sun, 20 Jul 2014 18:41: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: critical X-Bugzilla-Who: bugdal at aerifal dot cx X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: 2.19 X-Bugzilla-Flags: security- 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-07/txt/msg00652.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=12683 --- Comment #22 from Rich Felker --- Steven, I'm not sure I understand what you're saying. This issue report is not about changing which syscalls/functions are cancellable. For the standard functions that is specified by POSIX, and for extensions, the natural choices were already made and changing them would be problematic to their users. The topic at hand is just fixing the mechanism by which cancellation is performed so that there are not race conditions. If your question is about the syscall() function that applications can use to make syscalls directly, there is no open issue for making it cancellable, and as above, changing this would be problematic. One could envision a request for a separate version of the syscall() function which is cancellable, but as far as I know nobody has requested this and I think it's a bad idea to be adding features that encourage applications to make syscalls directly (since this is usually non-portable between archs due to subtle differences in the calling conventions and other issues like whether the libc-level structs match the syscall-level ones for a given arch). -- You are receiving this mail because: You are on the CC list for the bug.