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

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

Thread Previous | Thread Next
Nicholas Clark
January 21, 2001 05:16
Re: Does perl really need to use sigsetjmp? (18% performance hit)
Message ID:
On Sun, Jan 21, 2001 at 12:11:26PM +0000, Alan Burlison wrote:
> setjmp/sigsetjmp are NOT thread safe and CANNOT be used in a threaded
> program.  Period.  Perl5 uses setjmp even when built threaded, and is

Bah. I wasn't assuming that we were going to use them
But I'd forgotten the above.

> I'm not sure that starting a thread per eval context is a sensible thing
> to do.  Threads are cheap, but not that cheap.

it was more a brainstorming type idea.
It wouldn't also work, because the eval context would either have to copy
its invokers entire interpreter before starting, and then either "implode"
if it dies, or substitute its interpreter in place of its parents if it
doesn't die.
We don't actually need the new thread, as the invoker of the eval doesn't
run again until the eval finishes

> Basically there is no free lunch here - if we want to use threads and do
> exception handling in perl6 we will have to roll our own.  If perl6 has
> something akin to the perl5 stack, eval/die will have to be implemented
> so that that it rolls back up the stack on die, rather than the current
> longjmp hack.

This makes sense. I'm reasoning (well, guessing) that eval really needs
interpreter data structures that let us make a proposed set of changes,
and then roll back or commit them when the eval exits
(can any relational database nest transactions? if not, then perl has do to
something more than they do)

> Note that even if we used C++ it wouldn't help us in this case, because
> although C++ does exceptions, it knows nothing about threads, mutexes or
> CVs.  I suspect the perl6 interpreter loop will look something like:

I'm assuming that if you wrap up them up in a suitable object each, with
a destructor to release them, it can be taught to do them.

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

hey. we get a "sequence point" opcode. :-)

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

and with a sequence point opcode it would be easy to parse the op tree and

perl6 -wle '$a = 1; print ++$a / $a++'
Multiple modifications of variable '$a' in a single expression will give
unpredictable results.

Nicholas Clark

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