race condition fix: block all signals before decrementing thread count

the existence of a (kernelspace) thread must never have observable
effects after the thread count is decremented. if signals are not
blocked, it could end up handling the signal for rsyscall and
contributing towards the count of threads which have changed ids,
causing a thread to be missed. this could lead to one thread retaining
unwanted privilege level.

this change may also address other subtle race conditions in
application code that uses signals.

0 files changed, 0 insertions, 0 deletions