Re: cvs: php4 /ext/xml xml.c

"Rob Richards" <rrichards@ctindustries.net> wrote: > There are discussions on the libxml mailing list about implementing > functionality here. > Dont have the links right now but I believe it was the beginning of May of > this year when it started. > It sounds like the majority of it is going to be done for the next major > libxml version, but they are also talking about implementing some of it > within the 2.5 branch. Nothing is set in stone here, so I cant definitively > say how or when it will actually be implemented. Thanks for the pointer. I'll try to find it. > > In compat.c, xmlMemSetup() is called with XML_ParserCreate_MM() to > > initialise the libxml MM so it would take advantage of Zend allocators > > (emalloc family) instead of the plain libc allocators. I know that's a > > kind of bogus stuff, but then how should we handle it? > > > > 1. statically initialise them in PHP_MINIT_FUNCTION() in advance of any > > call of XML_ParserCreateMM() at runtime and ignore the second parameter > > passed to XML_ParserCreateMM(). > > > > 2. use the libc allocators in any way. > > You also need to remember that the xml extension is not the only extension > using libxml. The is also dom, simplexml, xsl and possibly the old domxml > extension. In order for everything to play nicely, it looks like you should > be statically initializing them in the PHP_MINIT_FUNCTION. These are globals > that are being changed which can affect all the other extensions using > libxml. Indeed. But as long as libxml allocators are designed to be initialised only in the xml extension, the order could be a problem in which those extensions are initialised on startup. Maybe I can make clones of the xmlMemSetup() code and paste them to the PHP_MINIT_FUNCTION() of every extension which uses libxml, but it hardly looks like a better solution. I'd asked you for more a practical option :) Moriyoshi