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.
