On Sun, 11 Feb 2001 21:11:09 -0500, "Bryan C. Warnock"
<[EMAIL PROTECTED]> wrote:
>On Sunday 11 February 2001 19:08, Jan Dubois wrote:
>> However, I couldn't solve the problem of "deterministic destruction
>> behavior": Currently Perl will call DESTROY on any object as soon as the
>> last reference to it goes out of scope. This becomes important if the
>> object own scarce external resources (e.g. file handles or database
>> connections) that are only freed during DESTROY. Postponing DESTROY until
>> an indeterminate time in the future can lead to program failures due to
>> resource exhaustion.
>
>But doesn't resource exhaustion usually trigger garbage collection and
>resource reallocation? (Not that this addresses the remainder of your
>post.)
Not necessarily; you would have to implement it that way: When you try to
open a file and you don't succeed, you run the garbage collector and try
again. But what happens in the case of XS code: some external library
tries to open a file and gets a failure. How would it trigger a GC in the
Perl internals? It wouldn't know a thing that it had been embedded in a
Perl app.
This scheme would only work if *all* resources including memory and
garbage collection are handled by the OS (or at least by a virtual machine
like JVM or .NET runtime). But this still doesn't solve the destruction
order problem.
-Jan
