public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "tpiepho at gmail dot com" <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: Thu, 15 Nov 2012 20:35:00 -0000 [thread overview] Message-ID: <bug-10815-131-8MymRmBdiC@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-10815-131@http.sourceware.org/bugzilla/> http://sourceware.org/bugzilla/show_bug.cgi?id=10815 --- Comment #4 from Trent Piepho <tpiepho at gmail dot com> 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.
next prev parent reply other threads:[~2012-11-15 20:35 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 2012-11-15 20:35 ` tpiepho at gmail dot com [this message] 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-8MymRmBdiC@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).