On 11 July 2013 08:11, ольга крыжановская <olga.kryzhanov...@gmail.com> wrote:
> Why does ksh93 use SIGALRM internally to implement sleep? It looks a
> bit byzantine, aside from the issue that the code in
> src/cmd/ksh93/sh/fault.c can never work, as intended:
> if(shp->savesig)
> {
> /* critical region, save and process later */
> if(!(shp->sigflag[sig]&SH_SIGIGNORE))
> shp->savesig = sig;
> return;
> }
> if(sig==SIGALRM && shp->bltinfun==b_sleep)
> {
> if(trap && *trap)
> {
> shp->trapnote |= SH_SIGTRAP;
> shp->sigflag[sig] |= SH_SIGTRAP;
> #ifdef _lib_sigaction
> set_trapinfo(shp,sig,info);
> #endif
> }
> return;
> }
>
> I can imagine so many problems caused by this.
> 1. if(shp->savesig)/return; - if this code is *ever* executed for a
> signal we loose the siginfo data for this signal.
shp->savesig is used when the shell forks a subshell to prevent that
signals are processed. Unfortunately it's the wrong solution at the
worst possible place, at least since the day when signals are
considered to be *reliable*.
IMO a solution would be to add a label to the siginfo data and the
label describes the subshell level the shell is currently in. If they
do not match the siginfo data we have 3 choices:
1. If the siginfo data are for the parent shell wait for the current
subshell level to exit and process the siginfo data then
2. If the siginfo data are for the current subshell level then process them
3. If the siginfo data are for a sushell which is gone throw them away
Ced
--
Cedric Blancher <cedric.blanc...@googlemail.com>
Institute Pasteur
_______________________________________________
ast-developers mailing list
ast-developers@lists.research.att.com
http://lists.research.att.com/mailman/listinfo/ast-developers
