On 3/2/22 02:45, Raffaello D. Di Napoli wrote:
On 3/1/22 16:57, Denys Vlasenko wrote:
On Tue, Mar 1, 2022 at 5:39 PM Denys Vlasenko
<vda.li...@googlemail.com> wrote:
Meanwhile: what "timeout" is doing is it tries to get out
of the way of the PROG to be launched so that timeout's parent
sees PROG (not timeout) as a child. E.g. it can send signals
to it, get waitpid notifications if PROG has been stopped
with a signal, and such.
And PROG also has no spurious "timeout" child.
"timeout" exists as an orphaned granchild.
That doesn’t seem to be a concern for coreutils, according to Rob’s
inspection. (I haven’t looked, but I’ll assume they still do signal
forwarding and everything that can be done cheaply.) Isn’t it a goal
of BB to avoid unnecessary divergence from coreutils?
Let's go with a solution with fd opened to /proc/PID?
I’d think simplifying the implementation and bringing it closer to
coreutils’ would be more in line with BB’s goals, instead of making it
larger and more complicated (especially considering how
counter-intuitive it is already, despite being fairly small).
It might be worth mentioning that busybox can't conform to coreutils
unless it does remain the parent process, because of this detail: (from
coreutils' timeout man page)
> If the command times out, and --preserve-status is not set, then
> exit with status 124. Otherwise, exit with the status of COMMAND.
timeout doesn't appear to be part of POSIX, though.
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
