Quoting Steffen Mueller <nj88udd02@sneakemail.com> from ml.lang.perl.porters: :(Raphael Manfredi) wrote: :> I do not want to recompile perl with my own macros. I want to link with :> plain stock -lperl then use an API from the perl library to supersede the :> memory allocation routines at runtime. :> :> I take from your answer that this API does not exist today and would have :> to be developped in order to do what I want. : :I wonder whether such an API wouldn't slow down the malloc routine :because it would have to check for user-supplied implementations. But :then again, I'm not known to be particularly clueful in all things C. The impact would be completely negligible. The only thing that is required is that a table of function pointers to malloc(), realloc() and free() be maintained by Perl and each time you want to perform a memory operation, you dereference the pointer from this table. Since these would be used fairly frequently, chances are the addresses there would be in the CPU cacheline from one of the L1, L2 or even L3 caches. Compared to the work that a malloc() routine or a free() routine has to do anyway, the extra dereference impact will not be noticeable. :Quoting perlvars.h: :PERLVARI(Grevision, U8, PERL_REVISION) :PERLVARI(Gversion, U8, PERL_VERSION) :PERLVARI(Gsubversion, U8, PERL_SUBVERSION) So accessing the PL_revision variable from C would give me access to Grevision? RaphaelThread Previous | Thread Next