On Sun, 11 Feb 2001 22:30:30 -0500, "Bryan C. Warnock"
<[EMAIL PROTECTED]> wrote:
>crossed to -internals
Ok, I removed -language.
>Jan Dubois:
>> 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.
>
>But that would be the point of the API, no? Even in XS, you'd interface
>through perl for memory or file management. So the core would still be
>able to invoke the GC. Granted, these are last-ditch efforts anyway - what
>would really be needed to trigger? E[MN]FILE? ENOMEM? Weird cases of
>ENOSPC? If you happen to hit one, force a GC pass, and retry whatever the
>call was. Even if the GC is unsuccessful (at resource reclamation),
>wouldn't you still want Perl to panic, vice the XS code anyway?
What about extensions using a statically linked version of libc? Or one
managing it's own resources? The XS glue code would then have to insert a
GC call after each external API call that failed. And the ugly thing is:
Even for a generational GC scheme you would have to GC *all* the memory
because you are not looking for some free memory, but hoping that some
object will free a resource. You don't know which generation to collect;
it could be anywhere.
Doing full GC in this fashion after failed API calls will probably wipe
out any performance gain mark-and-sweep has over reference counting.
>> 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.
>
>Well, no. My thought would be if A needed to be destroyed before B, then B
>wouldn't/shouldn't be marked for GC until after A was destroyed. It might
>take several sweeps to clean an entire dependency tree, unfortunately.
But *how* do you implement this dependency in a way that is *cheaper* than
reference counting? You can save some memory by only reference counting
objects and not simple values, but this increases runtime cost beyond
simply reference counting everything.
-Jan
