On 22/06/18(Fri) 22:37, Alexander Bluhm wrote:
> Hi,
>
> Since the recent futex(2) changes the posixtestsuite regress does
> not finish within the given time frame. Depending on some races
> tests hang, e.g. this one:
>
> /usr/local/libexec/posixtestsuite/conformance/interfaces/pthread_atfork/3-3.test
>
> It spans a worker thread that allows to handle SIGUSR1 or SIGUSR2.
> Two signal sending threads are created that kill the process with
> SIGUSR1 or SIGUSR2 repectively. The main thread and the signal
> sending threads block these signals. The signal handler in the
> worker thread uses semaphores to acknowledge signals and then the
> sending threads kill again.
>
> It may happen that the worker thread is in the signal handler and
> also blocks the signals.
Are you saying that the worker thread modified its mask itself, via
a syscall, or that the kernel changed `p_sigmask'?
> Then all threads block them and ptsignal()
> sends it to the main thread. In the test program the main thread
> blocks them forever and the process gets stuck.
Can you point us to the piece of code containing this logic? Is it:
* [...]. Otherwise, mark it pending on the
* main thread.
> According to POSIX any thread should process the signal when it
> unblocks.
Does that mean we should rather mark the signal pending on the thread
will unblock it? Do we have a way to know that it will unblock it (see
my first question)?
