From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30234 invoked by alias); 14 Nov 2012 17:38:09 -0000 Received: (qmail 28251 invoked by uid 48); 14 Nov 2012 17:37:44 -0000 From: "bugdal at aerifal dot cx" To: glibc-bugs@sources.redhat.com Subject: [Bug nptl/10815] [timer_create / SIGEV_THREAD] signalmask of timer_sigev_thread dangerous Date: Wed, 14 Nov 2012 17:38: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: bugdal at aerifal dot cx 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: Status CC Resolution 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/msg00116.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=10815 Rich Felker changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |bugdal at aerifal dot cx Resolution|WONTFIX | --- Comment #3 from Rich Felker 2012-11-14 17:37:42 UTC --- Drepper's comment is technically incorrect; the behavior is implementation-defined, not undefined. And in this case, glibc is actively providing detrimental behavior. I think this should be fixed. As Trent suggested, it may be convenient to have the signal mask match the mask at the time of the call to timer_create, but storing this and restoring it would be extra work. I think the most-correct behavior is for the timer thread always to start with all signals blocked. If the applications wants some signals unblocked, it can always unblock them as part of the timer handling code. But if any of them start out unblocked, it's impossible to block them without race conditions. Basically, this just comes down to common-sense about signal masking and race conditions. A library function (whether in the standard library or a third-party library) should NEVER unblock a signal unless that signal is only used for its own internal purposes (like the timer or cancellation signals). The only operations libraries ever perform on the signal mask should be blocking signals and restoring to a previously-saved mask. -- 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.