[Bug nptl/10815] [timer_create / SIGEV_THREAD] signalmask of timer_sigev_thread dangerous
tpiepho at gmail dot com
sourceware-bugzilla@sourceware.org
Thu Nov 15 20:35:00 GMT 2012
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.
More information about the Glibc-bugs
mailing list