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

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

Thread Previous | Thread Next
Alan Burlison
January 21, 2001 14:09
Re: Does perl really need to use sigsetjmp? (18% performancehit)
Message ID:
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.

> >   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.

Alan Burlison

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