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

["bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>]

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.