bug#8938: make timeout and CTRL-C

[Pádraig Brady]

On 07/07/11 12:13, Jim Meyering wrote:
> 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.

Good catch. I'll wrap in

#if HAVE_SETRLIMIT && defined RLIMIT_CORE
#endif

> 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.

I'll issue a warning.

cheers,
Pádraig.