Yep, that makes sense. Is there a reason why we don't link dynamicall to libxml2.dll? Makes all the sense in the world IMO and this has always been the common practice. I'm just worried that messing around with DllMain() will cause some problems down the road and having libxml2.dll is more flexible.
Andi > -----Original Message----- > From: Rob Richards [mailto:[EMAIL PROTECTED] > Sent: Friday, August 25, 2006 4:26 AM > To: Andi Gutmans > Cc: 'Edin Kadribasic'; internals@lists.php.net > Subject: Re: [PHP-DEV] libxml2/threading/win 2003 > > MINIT is definitely not the place for this. > The xmlDllMain call is meant to be called from within a dll's > DllMain that includes libxml statically. > How threads are handled differs between the old static build > and the one for inclusion within a dll. > When a thread (all except the main thread) terminate > currently xmlDllMain makes sure that everything for the > thread is properly cleaned up. > > When the function needs to be called is really dependant upon > how the PHP dll is loaded (in process, out of process, > etc..). I am not sure of the states running under Win 2003, > but from what I guess reading the reports is that it is out > of process and a timing issue when not everything from one of > the spawned threads is cleaned up prior to the main thread > being cleanedup. > > Also right now the function only handles the xmlDllMain > DLL_THREAD_DETACH message, but what happens if other messages > need to be handled? > > The only way to eliminate the need for this call, a DllMain > and the new static build of libxml2 is to no longer build it > in staically and use the dynamically loaded libxml2.dll. > > Rob > > > Andi Gutmans wrote: > > Rob, > > > > Is there a reason why we can't call this from MINIT? I'm not sure a > > good long-term solution is to have a DllMain when we don't need one. > > > > Andi > > > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
