public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org> 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 [thread overview] Message-ID: <bug-10815-131-0J8Zeertuc@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-10815-131@http.sourceware.org/bugzilla/> http://sourceware.org/bugzilla/show_bug.cgi?id=10815 Rich Felker <bugdal at aerifal dot cx> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |bugdal at aerifal dot cx Resolution|WONTFIX | --- Comment #3 from Rich Felker <bugdal at aerifal dot cx> 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.
next prev parent reply other threads:[~2012-11-14 17:38 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-10815-131@http.sourceware.org/bugzilla/> 2012-11-13 23:44 ` tpiepho at gmail dot com 2012-11-14 17:38 ` bugdal at aerifal dot cx [this message] 2012-11-15 20:35 ` tpiepho at gmail dot com 2012-11-15 23:48 ` bugdal at aerifal dot cx 2014-07-01 5:38 ` fweimer at redhat dot com 2015-08-27 22:11 ` [Bug librt/10815] " jsm28 at gcc dot gnu.org 2009-10-20 10:11 [Bug nptl/10815] New: " roland dot lezuo at chello dot at 2009-10-20 11:31 ` [Bug nptl/10815] " drepper at redhat dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-10815-131-0J8Zeertuc@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sources.redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).