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 02:56
Re: Does perl really need to use sigsetjmp? (18% performance hit)
Message ID:
On Sat, Jan 20, 2001 at 02:14:53PM -0500, Dan Sugalski wrote:
> I'd rather not use setjmp/longjmp in perl 6 if we can avoid it. I 
> definitely don't want to design things such that its existence is required.

Hmm. So does this mean that it's likely that most functions will be returning
"Life goes on" or "Wake up, time to die" ?
Or that there will be "die" flag that gets set and then checked at the end
of each op?
Or that (assuming we are using threads) each eval context also gets a new
thread, and die exits the the thread pronto?

I guess it depends on the ratio between the cost of setting up an eval
context, and the cost of checking the vital signs (which in turn is a
weighted average of the cost of finding out it's all clear multiplied by the
large number of times we expect not to die, and the cost of finding out
we're supposed to be dead and ending things right there)

Currently it's cheap to sigsetjmp (I'm assuming compared with setting up a
whole thread) but expensive to keep checking
Setting up a thread would be expensive, but there's not cost involved in
checking that the thread you're running in is still running!
[can we attach enough things to thread exit to tidy up what needs tidying?]

(I guess in one sense in single threaded perl in Unix with no child
processes one way to do eval would be to fork - if the eval dies, it exits
and the parent carries on as if nothing had happened. If the eval succeeds,
the parent dies, and the child carries on as if there never was a parent.
I think (that way) you get total undo of any effects of the eval, with
no resource leaks, which I believe is what it is desired for it to do.

Nicholas Clark

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