Front page | perl.perl6.language |
Postings from February 2001
On Sun, 11 Feb 2001 21:11:09 -0500, "Bryan C. Warnock" <bwarnock@gtemail.net> 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. -JanThread Previous | Thread Next