Re: Add on_perl_init and proper destruction to plperl [PATCH]

On Wed, Jan 27, 2010 at 06:33:19PM -0500, Tom Lane wrote:
> Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com> writes:
> > On Wed, Jan 27, 2010 at 11:28:02AM -0500, Tom Lane wrote:
> >> Really? We've found that gprof, for instance, doesn't exactly have
> >> "zero interaction with the rest of the backend" --- there's actually
> >> a couple of different bits in there to help it along, including a
> >> behavioral change during shutdown. I rather doubt that Perl profilers
> >> would turn out much different.
>
> > Devel::NYTProf (http://blog.timbunce.org/tag/nytprof/) has zero
> > interaction with the rest of the backend.
>
> I don't have to read any further than the place where it says "doesn't
> work if you call both plperl and plperlu" to realize that that's quite
> false.

NYTProf is not, currently, multiplicity-safe. That's a limitation I
intend to fix.

> Maybe we have different definitions of what a software interaction is...

Doing _anything_ in the backend is an interaction of some kind, e.g.,
shifting later memory allocations to a different address. But that's not
a very practical basis for a definition.

From what you said, quoted above, it seemed that your definition of
"interaction with the rest of the backend" was more much more direct.
The specific example you gave related to the backend code needing to be
modified to support the gprof profiler. Clearly that's not the case for
NYTProf.

We're splitting hairs now.

Tim.