Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>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.
> True but, and this is the good part, that's not our problem. It is, I
> think, safe to assume that language compilers that want timely
> destruction will make sure to clean up after themselves sufficiently
> to make that timely destruction possible. It's our job to provide the
> mechanisms they need, and leave it to them to use them as needed.
> In other words, we punt it to someone else. :)
I'd prefer such a solution too. But:
{
my $fh = open(..);
foo(1, $h);
}
which could be some PIR like:
new_pad -1
$P0 = Pio."open"()
store_lex -1, "$fh", $P0
foo(1, $P0);
pop_pad
sweep 0
with some corresponding PASM (pdd03 call registers ignored for brevity)
new_pad -1
set P2, Px
callmethodcc "open"
set P16, P5
store_lex -1, "$fh", P16
set I5, 1
set P6, P16
set_p_pc P0, "foo"
invokecc
pop_pad
sweep 0
Now we have the filehandle scattered and duplicated in P registers. There
is no chance for a HLL to emit "null Px" to clear involved registers as
the information, where each temp is located, isn't available.
At scope exit the filehandle is alive in registers and not closed.
leo
