Front page | perl.perl5.porters |
Postings from January 2001
Mark Mielke <markm@nortelnetworks.com> writes:
>On Tue, Jan 09, 2001 at 02:20:57PM +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.
>
>It seems, from the conversation here, that an assumption I've made about
>the Perl implementation is incorrect. (It wouldn't be the first time)
>
>Why is a sigsetjump() needed at _all_ except for eval{} blocks?
It isn't needed for all eval {} either, only those involving signals.
>
>Is it too much housekeeping to have the sigsetjump() know where it was
>on the stack at a given time and backtrack all contained blocks to
>perform cleanup (for blocks that were exitted via the longjmp()), with
>normal "end of block" opcodes cleaning up for themselves?
Probably not - but we would need to distinguish two kinds of contexts
(jmpbuf for normal-block longjmp and sigjmpbuf for ones which really
are siglongjmp and a flag to say which is what).
Patches welcome ;-)
>
>TCL, for instance, doesn't use setjump() at all for blocks or loop.
But Tcl returns the equivalent of perl's $@ from every single call
to anything. There is a per-interpreter "result" and a flag to say
if it actually a result or string value of $@.
Which means the "real" return value is elsewhere or has to be gated
which complicates the flow no end.
Despite the sigsetjmp() perl was faster then even Tcl_Obj style Tcl
at run time.
>
>Does it speed up "next", "redo", and "last" operations? Is that why
>it does it on every block?
>
>mark
>
>--
>markm@nortelnetworks.com/mark@mielke.cc/markm@ncf.ca __________________________
>. . _ ._ . . .__ . . ._. .__ . . . .__ | SIR Tools (7H12)
>|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | Nortel Networks
>| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
>
> One ring to rule them all, one ring to find them, one ring to bring them all
> and in the darkness bind them...
>
> http://mark.mielke.cc/
--
Nick Ing-Simmons
Thread Previous
|
Thread Next