bug#8938: make timeout and CTRL-C

[Jim Meyering]

Pádraig Brady wrote:

> On 07/07/11 11:05, Pádraig Brady wrote:
>> On 06/07/11 23:37, Pádraig Brady wrote:
>>> OK I've added --foreground to support this.
>>> Note it still maintains a separate timeout
>>> monitor process to return 124 on timeout etc.
>>
>> Updated wording and NEWS entry now included.
>> I'll push this later today.
>
> I'm also thinking of pushing this as a separate patch,
> which will set WIFSIGNALED for the timeout process itself.
> This will make timeout more transparent and when doing
> Ctrl-C from make for example, printing "[target] Interrupt"
> rather than "[target] Error 130".
>
> diff --git a/src/timeout.c b/src/timeout.c
> index a686225..ea4af18 100644
> --- a/src/timeout.c
> +++ b/src/timeout.c
> @@ -341,7 +361,19 @@ main (int argc, char **argv)
>            if (WIFEXITED (status))
>              status = WEXITSTATUS (status);
>            else if (WIFSIGNALED (status))
> -            status = WTERMSIG (status) + 128; /* what sh does at least.  */
> +            {
> +              int sig = WTERMSIG (status);
> +              if (!timed_out)
> +                {
> +                  /* exit with the signal flag set, but avoid core files.  */
> +                  if (setrlimit (RLIMIT_CORE, &(struct rlimit) {0,0}) == 0)
> +                    {
> +                      signal (sig, SIG_DFL);
> +                      raise (sig);
> +                    }
> +                }
> +              status = sig + 128; /* what sh returns for signaled processes. 
>  */

I like the idea.
Note that setrlimit is not available on mingw or Beos, according to
gnulib's doc/posix-functions/setrlimit.texi, so you might want to test
for its existence.  Otherwise, this change would induce link failure on
those systems.

At first I was worried that this improvement would be dependent on
setrlimit success, but it appears that it cannot fail for the arguments
used here.  I wonder if it's better to assert that non-failure -- or
maybe just issue a warning, so that if it happens we'll be more likely
to get a bug report about it, rather than have users endure a subtle
difference in behavior.