Marvin Humphrey wrote on 11/8/11 7:32 PM:
> As far as I can tell, the only solution is to disconnect our DESTROY methods
> when Perl enters global destruction and leak everything. Here's sample XS
> code to get the point across:
>
> void
> DESTROY(self)
> lucy_IndexSearcher *self;
> PPCODE:
> if (PL_phase != PERL_PHASE_DESTRUCT) {
> lucy_IxSearcher_destroy(self);
> }
>
> Of course, this defeats the purpose of the change that was made in Perl 5.15.
> The rationale for the new behavior is to support situations where for example,
> you could guarantee that when a Perl interpreter in an embedded system shuts
> down, *everything* gets reclaimed. But I believe that architecture is only
> feasible when you control all memory allocation (as when the OS closes a
> process) and thus Perl's new global destruction model is flawed as it cannot
> encompass external resources.
>
Would it help if Perl's global destruction phase called DESTROY() with an
argument in order to indicate that it was in that phase? Or is that
PERL_PHASE_DESTRUCT var supposed to achieve that? Is that real code?
I guess what I'm getting at is, who cares if the change to Lucy defeats the
purpose of the Perl feature. The change to Perl is supposed to address a problem
that Lucy does not have. We already do Perl version checks where the API has
changed (as in regex handling). Does putting that PERL_PHASE_DESTRUCT check in
there work around the issue with no ill side effects to Lucy? Could we just plow
through the code, add that check, and call it a day?
> I wonder how many other systems like ours are out there that are vulnerable to
> this flaw. Not many CPAN distros are going to have test suites that validate
> behavior under refcount leakage.
fwiw, SWISH::3 is largely C/XS and it is apparently passing its 5.15 tests right
now according to cpantesters. I don't have the same VTable architecture in
there, but as you'll remember Marvin, the object and memory management model was
inspired by our conversations around how Lucy does it.
--
Peter Karman . http://peknet.com/ . [email protected]
