hush: initial trap support

[Mike Frysinger]

On Sunday 29 March 2009 15:53:16 Denys Vlasenko wrote:
> 2009/3/29 Mike Frysinger <vapier at gentoo.org>:
> > On Sunday 29 March 2009 11:24:10 Denys Vlasenko wrote:
> >> (a) I prefer all data to go to struct globals, never to .data.
> >> (b) It would be nice to allocate it on first use, it's big
> >>     (so that scripts which never use traps don't waste memory for it).
> >> (c) int sig; const char *name; is wasting 8 bytes,
> >>     uint8_t sig; char name[7]; is more compact.
> >> (d) libbb has get_signum(str) which already does signal name or number
> >> -> signal number conversion. get_signame(num) is an opposite convertor.
> >> Use them, this allows you to not duplicate signal names.
> >
> > using the common sig funcs to do translation allows for quite a bit of
> > reduction.  delaying the alloc also saves on bloat.  i was hoping there
> > was a way we could unify the code so that hush wouldnt have to
> > save/restore the sigaction at all though.
>
> This is possible, but is it worth the trouble? struct sigaction is not
> THAT big. Let's make it work correctly first.
>
> > it'd know which ones hush wants to handle (like for
> > CTRL+Z and CTRL+C) ... that may save on allocated data, but not really
> > code, so maybe it isnt worth the hassle.
> >
> > updated patch attached
>
> +       max_sig = get_sig_array_size();
> +       if (!G.traps)
> +               G.traps = xzalloc(sizeof(*G.traps) * max_sig);
>
> You need to use NSIG here, because
>
> +size_t FAST_FUNC get_sig_array_size(void)
> +{
> +       return ARRAY_SIZE(signals);
> +}
>
> returns the size of "known signal names" table,
> but we need to have table as big as all *possible* signals.
> NSIG is usually 65, meaning that there exist signals 1..64

the shell is required to support only known signals:
http://www.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html
all of those signals are listed in the known signal names table and i use 
those signal functions to verify.  but i guess since you can use `kill` to 
send an undefined signal #, and supporting 0..NSIG is easy, we can do that.

> >> Add a comment somewhere that we improperly execute traps at once
> >> (even within, say, malloc() calls... which is rather bad)
> >> while we need to wait for latest command completion.
> >
> > i dont follow you here ... no idea what you're talking about actually :)
>
> bash:
>
> # echo $$; trap "echo USR1" USR1; sleep 10
> 9891
> < I run kill -USR1 9891 in other xterm >
> USR1  < appears only after 10 seconds >
> #
>
> IOW, traps are not executed *immediately* when signal is received.
> They happen after last command has terminated (or was ^Z-ed).

ok, i'll take a look ... i'm not optimistic about supporting this early on 
though ...
http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_11
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20090329/f2979f27/attachment.pgp>