Front page | perl.perl5.porters |
Postings from January 2001
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 ClarkThread Previous | Thread Next