From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27439 invoked by alias); 15 Nov 2012 20:35:19 -0000 Received: (qmail 22552 invoked by uid 48); 15 Nov 2012 20:35:05 -0000 From: "tpiepho at gmail dot com" To: glibc-bugs@sources.redhat.com Subject: [Bug nptl/10815] [timer_create / SIGEV_THREAD] signalmask of timer_sigev_thread dangerous Date: Thu, 15 Nov 2012 20:35: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-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: tpiepho at gmail dot com X-Bugzilla-Status: REOPENED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: drepper.fsp at gmail dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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 X-SW-Source: 2012-11/txt/msg00132.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=10815 --- Comment #4 from Trent Piepho 2012-11-15 20:35:03 UTC --- The signal mask is already stored by code in the timer_create() call, so using that mask in the timer thread doesn't actually take any more work that is done now. It's just as matter of changing two existing rt_sigprocmask calls to use a global rather than a local variable. But thinking about it more, I agree with Rich that blocking all signals is the only sensible way. The sigprocmask call in the timer thread can be removed. The user code can always add it back and unblock whatever it wants unblocked if it cares. If it doesn't, then the call is avoided. Restoring the mask used when calling timer_create() wouldn't work if the process has since blocked a signal. For instance, if it needs to modify a data structure also used by a signal handler, it's necessary to block the signal while doing so to avoid racing with the handler. If a completely unrelated timer goes off and creates a new thread with unblocked signals.... -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.