Re: [PATCH 2/4] nptl: Handle EPIPE on tst-cancel2

[Florian Weimer <fweimer at redhat dot com>]

* Adhemerval Zanella:

> The SIGPIPE can be handled before SIGCANCEL, which makes write fail
> and the thread return a non expected result.
>
> Checked on x86_64-linux-gnu.
>
> 	* nptl/tst-cancel2.c (tf): Do not abort with EPIPE.
> ---
>  nptl/tst-cancel2.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/nptl/tst-cancel2.c b/nptl/tst-cancel2.c
> index 1f0429d343..632ea4e0ae 100644
> --- a/nptl/tst-cancel2.c
> +++ b/nptl/tst-cancel2.c
> @@ -20,6 +20,7 @@
>  #include <signal.h>
>  #include <stdio.h>
>  #include <unistd.h>
> +#include <errno.h>
>  
>  
>  static int fd[2];
> @@ -32,7 +33,14 @@ tf (void *arg)
>       write blocks.  */
>    char buf[100000];
>  
> -  while (write (fd[1], buf, sizeof (buf)) > 0);
> +  while (1)
> +    {
> +      /* Ignore EPIPE errors for case the SIGPIPE is handle before
> +	 SIGCANCEL.  */
> +      ssize_t ret = write (fd[1], buf, sizeof (buf));
> +      if (ret == 0 || (ret == -1 && errno != EPIPE))
> +       break;
> +    }
>  
>    return (void *) 42l;
>  }

I disagree with this change.  SIGPIPE does not appear to be a valid
error from write in this test because the thread is canceled before the
read end of the pipe is closed.  POSIX says this:

| The cancellation processing in the target thread shall run
| asynchronously with respect to the calling thread returning from
| pthread_cancel().

But that doesn't mean that the thread can observe actions in its
uncanceled state that happen after the cancellation, which is the case
when the write fails with SIGPIPE.

Thanks,
Florian