lock in test_sigaction

[TheJonny]

What does this PR do

sigaction is process global, i think we should lock the signal handling mutex here to serialize this test

[TheJonny]

ok, it does not fix the issue:
https://github.com/nix-rust/nix/actions/runs/8703439323/job/23869616222?pr=2375

[SteveLauC]

ok, it does not fix the issue: https://github.com/nix-rust/nix/actions/runs/8703439323/job/23869616222?pr=2375

Yeah, this is indeed something hard to deal with:<

[TheJonny]

@SteveLauC what do you think about using a RWLock instead of the Mutex for the SIGNAL_MTX? Then tests for process wide functions could lock it for write, and functions for thread local functions lock it for read?

from my understanding of POSIX / Linux, process wide are: sigaction, signal, sigsuspend, sigprocmask
and thread local are: pthread_sigmask, the sigwait family, and signalfd

I think keeping the tests affecting just one thread in parallel is a good thing as it might catch some bug

[SteveLauC]

Even though the this patch presented in this PR does not fix the issue, I think we still need to grab the lock in the test_sigaction(), thanks for catching it!

from my understanding of POSIX / Linux, process wide are: sigaction, signal, sigsuspend

Do you mean that sigsuspend() calls sigprocmask() under the hood to alter the signal mask?

What do you think about using a RWLock instead of the Mutex for the SIGNAL_MTX?

I think keeping the tests affecting just one thread in parallel is a good thing as it might catch some bug

Do you mean to increase concurrency so that we can reproduce the bug more easily and possibly get more information?

[TheJonny]

Do you mean to increase concurrency so that we can reproduce the bug more easily and possibly get more information?

I want to decrease concurrency: Right now, the tests touching only the thread local signal mask do not lock SIGNAL_MTX.
This races with the sigprocmask test. To prevent this, we could prevent the concurrency and take the Mutex in the functions that block signals for a single thread, but I think this would be too much as it would hide bugs.

So we need a Mutex that can be taken exclusively, while we manipulate the whole process, or shared, while we only use pthread_sigmask.

[TheJonny]

@SteveLauC After reading the previous comment, you can close this, as it is the same as your #2381 :)

[TheJonny]

Do you mean that sigsuspend() calls sigprocmask() under the hood to alter the signal mask?

I misread something and thought that sigsuspend would change the process signal mask - but posix 2008 and 2017 clearly say "thread", so never mind :)

[SteveLauC]

I want to decrease concurrency: Right now, the tests touching only the thread local signal mask do not lock SIGNAL_MTX.
This races with the sigprocmask test. To prevent this, we could prevent the concurrency and take the Mutex in the functions that block signals for a single thread, but I think this would be too much as it would hide bugs.

Oh I get it, I am willing to give it a try:)

[SteveLauC]

Close as it has been superseded by #2381