On 12 June 2013 18:56, Cedric Blancher <[email protected]> wrote:
> On 12 June 2013 13:46, Glenn Fowler <[email protected]> wrote:
>> the ast-ksh 2013-06-11 alpha source has been posted to
>> http://www.research.att.com/sw/download/alpha/
>> its still a work in progress
>> dgk and I are corrdinating the new vmalloc implementation vs signals
>> in addition to the work dgk is doing in ksh vs signals
>
> signals still do NOT work. For example my test below should print (
> typeset -l -E i=200.00200 ) but as you can see below it doesn't sum
> up:
> ksh -c 'compound a=(float i=0) ; trap "((a.i+=.00001));kill -USR2 $$&
> :" USR1 ; trap "((a.i+=1))" USR2 ; for ((j=0;j<200;j++));do kill -USR1
> $$&;done ; true ; while ! wait ; do true;done;print ${a}'
> ( typeset -l -E i=58.00094 )
> ksh -c 'compound a=(float i=0) ; trap "((a.i+=.00001));kill -USR2 $$&
> :" USR1 ; trap "((a.i+=1))" USR2 ; for ((j=0;j<200;j++));do kill -USR1
> $$&;done ; true ; while ! wait ; do true;done;print ${a}'
> ( typeset -l -E i=24.00048 )
I noticed some problems in the code:
+#ifdef _lib_sigaction
+ static void set_trapinfo(Shell_t *shp, int sig, siginfo_t *info)
+ {
+ sigset_t set,oset;
+ if(!shp->siginfo)
+ shp->siginfo = (void**)calloc(sizeof(void*),shp->gd->sigmax);
This should IMO not be done in the signal handler. if multiple signal
handlers are running stacked on each other it may cause a race
condition between the if(!shp->siginfo) and the value assignment to
shp->siginfo.Actually the timing window is quite huge.
+ if(info)
+ {
+ struct Siginfo *jp,*ip;
+ sigfillset(&set);
+ sigprocmask(SIG_BLOCK,&set,&oset);
+ ip = malloc(sizeof(struct Siginfo));
+ sigprocmask(SIG_UNBLOCK,&oset,&set);
+ ip->next = 0;
+ memcpy(&ip->info,info,sizeof(siginfo_t));
+ if(!(jp=(struct Siginfo*)shp->siginfo[sig]))
Isn't SIG_BLOCK a good way to loose signals? What happens if new
signals arrive while the signal block is active? Are they queued or
discarded? I think they are discarded and the time spend in the
allocator gives another large window of opportunity to screw up and
loose more signals.
Ced
--
Cedric Blancher <[email protected]>
Institute Pasteur
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
