Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:19 AM +0100 12/14/04, Leopold Toetsch wrote:
> Which does argue that it ought not be a sub, I suppose, but something
> simpler. A plain bsr sort of thing.
A bsr doesn't change anything. It has to return to the caller. That
thing, where it's returning to, is alive.
>>If the cleanup handler is a plain subroutine, the previous one, which
>>should be cleaned, is alive. A lazy DOD will find the filehandle in the
>>lexicals and likely in registers.
> Well, maybe. Subs are going to have multiple scopes in them (which
> argues for a faster-than-sub cleanup handler dispatch) so it's more
> than just a 'cleanup before leaving the sub' sort of thing. There's
> an awful lot of code around that looks like:
> sub foo {
> # Insert code here
> foreach (@some_array) {
> }
> {
> # Some code that needs its own block
> }
> if (foo) {
> } else {
> }
> }
> Besides cleaning up on sub exit, there's also a potential cleanup
> when the foreach is left, the bare block is left, and each of the
> legs of the if are left. (Potentially once on each foreach iteration,
> I suppose)
Yes. I'll presume that the first Perl6 compiler will just emit closures
for each block. But if no handle on this closure is kept they'll likely
end up as nested scopes. For both we need a sequence:
pop_pad
sweep 0
this could be one opcode (the pop_pad isn't needed, if it's a sub exit)
scope_exit
But that still doesn't solve the problem that a file-handle (after
cleaning lexicals) is still in a PMC register, when the C<sweep 0>
opcode is run.
leo
