crossed to -internals 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? > > 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. -- Bryan C. Warnock bwarnock@(gtemail.net|capita.com)
