This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug nptl/10815] [timer_create / SIGEV_THREAD] signalmask of timer_sigev_thread dangerous


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]