Front page | perl.perl5.porters |
Postings from January 2001
On Tue, Jan 09, 2001 at 02:27:38PM -0500, Dan Sugalski wrote:
> At 02:20 PM 1/9/01 +0000, Alan Burlison wrote:
> >No, I think you are right. However the whole
> >signal/eval/die/setjmp/longjmp mess is pretty much broken anyway, what
> >with the non-MT safeness and the current bizzare behaviour illustrated
> >by Raphaels test script.
> >
> >I'm still intending to disable sigsetjmp - I havn't heard any decent
> >reason for it being used.
> >
> >Roll on perl6...
>
> Well, besides "Just don't *do* that," any thoughts on how to handle this
> properly in p6?
Why is perl5 using setjmp (of any sort?) Is it to allow a simpler style of
exception handling when die() is called? Simply longjmp direct to the
enclosing scope, rather than have to write every function to return some
sort of "I'm dieing" flag, having to test each function called to see if we
should return immediately to our caller with the die flag (a right faff, and
probably slow]. In otherwords, to emulate something like the throw and catch
of C++?
If so, were we intending to use the same idea in perl6? Because it worries
me that with the setjmp()/longjmp() system anything like:
myfunc {
foo = malloc(something);
some_other_func(...);
free(foo);
}
will leak resources if some_other_func (or any of its descendants) jumps
past us. At least with C++, throwing exceptions calls destructors on the way
past each stack frame.
Or have I missed something?
Nicholas Clark
Thread Previous
|
Thread Next