Bug 19233

Summary: Add a --timeout <time-in-second> argument to abidiff
Product: libabigail Reporter: Dodji Seketeli <dodji>
Component: defaultAssignee: Dodji Seketeli <dodji>
Status: RESOLVED WONTFIX    
Severity: enhancement CC: andrew.c.morrow, cqi, libabigail
Priority: P2    
Version: unspecified   
Target Milestone: ---   
Host: Target:
Build: Last reconfirmed:

Description Dodji Seketeli 2015-11-12 09:03:26 UTC
To shield programs that call abidiff against runs that could possibly take too much time, a --timeout option would be appropriate.

That option would take an argument N in seconds.

If abidiff does not complete before N seconds, its execution would be aborted and a message would be emitted on the standard error output, saying that the execution has been aborted because it could not be performed within N seconds.

One possible way to implement this could be by using a combination of fork, exec, waitpid, alarm an kill system calls.
Comment 1 Chenxiong Qi 2015-11-12 10:33:16 UTC
What return code will be returned. Non-zero would be a choice.

The test results by the part of check that is already done still outputs. I think it would make sense.
Comment 2 andrew.c.morrow 2015-11-12 15:29:26 UTC
I'd like this for abidw as well, so that for my build system usage, if abidw takes too long, I can bail out and do a normal content signature, rather than the ABI based one.
Comment 3 Dodji Seketeli 2015-11-12 15:48:39 UTC
Some people have proposed that we just use the program 'timeout',
provided by coreutils, for this use case.

The reason why I was thinking about having a --timeout option was to
have a finer control about what we return in that case.

Right now, the 8 bits exit value of abidiff tells us about the kind of
difference or error encountered.  In case of timeout error (and if
abidiff handles --abidiff), we could flip the first bit (which mean
there was an error) and then flip the third bit too, saying that there
was a timeout.

Otherwise, if users use the "timeout" program from coreutils, handling
the exit code gracefully seems a little bit more bumpy.

What do you think?
Comment 4 Dodji Seketeli 2016-04-14 13:58:28 UTC
OK, finally, I think that just using the "timeout" program from coreutils is a better solution.

I don't really see a compelling reason for not using that one.