develooper Front page | perl.perl5.porters | Postings from January 2001

Re: Does perl really need to use sigsetjmp? (18%performancehit)

Thread Previous | Thread Next
Dan Sugalski
January 21, 2001 14:33
Re: Does perl really need to use sigsetjmp? (18%performancehit)
Message ID:
At 10:09 PM 1/21/01 +0000, Alan Burlison wrote:
>Dan Sugalski wrote:
> > >In other words the C level signal handler will have to do no more than
> > >setting a flag, as will the implementation of die().  By cancellation
> > >point I mean somewhere that is defined as 'safe', i.e. not holding any
> > >mutexes or waiting on any CVs etc.
> >
> > I'm not sure the core should really care about that. It's arguably not the
> > interpreter's problem. (Though it's not a strong argument)
>Ah - I mean not holding locks etc inside the interpreter core, not in
>the application.  Fixing the application is the application programmers
>problem ;-)  Seriously, I'm not sure that we could fix the genric
>application-level problem even if we wanted to.  However, we *could*
>probably get it right for the interpreter innards.

Oh, right. Hard and fast rule is that no internal locks will be held across 
an opcode boundary, period. Yeah, we may need to do odd things for sub 
calls and evals so we don't recursively fire off runops loops, but I'm OK 
with that, and I don't see where it should cost us anything anywhere but in 
the actual sub call and eval opcode functions.

Beyond that, I'm tempted to have the thread docs be one sentence:

    Go for it, and good luck!


> > >   I suspect a reasonable thing might
> > >be to have a special 'Now it is safe' opcode that is put out by the
> > >compiler at the appropriate places.  It would be nice if this
> > >corresponded to a syntactic boundary such as an entire statement, so
> > >that for example
> > >
> > >         my $a = $b * $c / $d;
> > >
> > >was guaranteed to either to be fully evaluated or not at all.
> >
> > The question, then, is what do we do with function calls in there (say, $a
> > = $b + foo()), and what about really long running statements like:
> >
> >    $a = $b + 12 while 1;
>Hmm.  Good point.  Actually, I'd just settle for any point that didn't
>result in the interpreter being screwed up afterwards.

Works for me. The big reason to go sub-statement is for better 
responsiveness, but then it firing off threads is simple enough we can tell 
folks that's what they should do if they want their events handled with 
reasonably small latency.


--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai                         have teddy bears and even
                                      teddy bears get drunk

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About