On Thu, Jul 11, 2013 at 9:36 AM, Cedric Blancher
<[email protected]> wrote:
> On 11 July 2013 08:11, ольга крыжановская <[email protected]> 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

The idea is good but IMO we need a subshell id (unique identifer) and
not a label which describes the nesting level... otherwise we end-up
with issues where signals created for one subshell may "bleed through"
into another subshell at the same nesting level, e.g. for $ ( ( sub1 )
( sub2 ) ( sub3 ) ) # signals created in "sub1" may bleed through to
"sub2".
Each subshell id should be "unique" for a given shell instance, e.g.
by using a |volatile int64_t| counter... each incoming siginfo data
package is then "tagged" with this subshell id and only the matching
level for which the signals arrived for should process it.

David... what do you think ?

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) [email protected]
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers

Reply via email to