incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Karman <pe...@peknet.com>
Subject Re: [lucy-dev] Non-deterministic destruction in Perl 5.15
Date Wed, 09 Nov 2011 01:53:03 GMT
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/  .  peter@peknet.com

Mime
View raw message