Andi,
After spending some more time looking at the Zend2 code it appears that
it does still have the same issue that I'm seeing in Zend1 (first ISAPI
thread gets the global compiler_globals as it's own personal copy). I
can't get the same debug output as I was able to for Zend1, but I am
seeing similar error messages (mostly about classes being already
defined that aren't).
I've continued to dig around in the Zend1 code and still believe that
the first thread is using the globals as it's own copy. In one of the
earlier messages you said that this shouldn't be happening. In
zend_startup() the startup thread's copy of compiler_global is set to
be the GLOBAL_*_TABLES version:
compiler_globals = ts_resource(compiler_globals_id);
executor_globals = ts_resource(executor_globals_id);
tsrm_ls = ts_resource_ex(0, NULL);
compiler_globals_dtor(compiler_globals, tsrm_ls);
compiler_globals->function_table = GLOBAL_FUNCTION_TABLE;
compiler_globals->class_table = GLOBAL_CLASS_TABLE;
compiler_globals->auto_globals = GLOBAL_AUTO_GLOBALS_TABLE;
I can't find anything in the code that runs after this that would reset
this thread's compiler_globals to be it's own local copy again. Can
you explain where you think this should be happening so I can try to
track it in my setup? Maybe this is somehow ISAPI specific.
As a follow-up test I created a version of 4.2.3RC1 with a new external
function in zend.c:
void zend_startup_done()
{
#ifdef ZTS
zend_compiler_globals *compiler_globals;
zend_executor_globals *executor_globals;
TSRMLS_FETCH();
compiler_globals = ts_resource(compiler_globals_id);
compiler_globals_ctor(compiler_globals, tsrm_ls);
executor_globals = ts_resource(executor_globals_id);
executor_globals_ctor(executor_globals, tsrm_ls);
#endif
}
This function will create a new compiler_globals and executor_globals
for the current thread and reinitilize them with the constructors. I
then added a call to this function as the last step of the ISAPI's
DLL_PROCESS_ATTACH code. I've tested and it appears to fix the
problems I was having with using the ISAPI module just as my version
that spun off a new thread for the initialization did.
Michael
--- Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Any chance you can setup and Engine 2 build and see if this problem
> persists?
>
> Andi
>
> At 06:42 AM 8/27/2002 -0700, Michael Sisolak wrote:
>
> >--- Zeev Suraski <[EMAIL PROTECTED]> wrote:
> > > At 09:53 27/08/2002, Michael Sisolak wrote:
> > > > > >i've been doing some debugging of the crashes when running
> php
> > > under
> > > > > >the isapi sapi. is anybody else currently looking at this?
> if
> > > you
> > > > > >are let's talk - here are my notes so far.
> > > > >
> > > > > first off, can you try using
> > > > > http://www.php.net/~zeev/php-4.2.3rc1.tar.gz
> > > > > and see if you experience the same problems? i've made some
> > > > > thread-safety related fixes there, even though none should
> lead
> > > > > to a hard crash...
> > > >
> > > >zeev,
> > > >
> > > >i believe that i may have tracked down a major isapi filter
> > > >thread-safety hole. if i understand what zend_startup() is
> doing
> > > >correctly, it assumes that the thread that it runs under will
> not
> > > also
> > > >be used to serve http requests.
> > >
> > > No, the startup thread can be used as a regular HTTP thread,
> nothing
> > > in the
> > > code should prevent that.
> > > The globals code in the startup sequence is very tricky, but it
> > > should work.
> >
> >This is a sample of the debug output that I'm seeing (this is PHP
> 4.2.1
> >running under Windows 2000 Professional, single CPU):
> >
> >[1948] the startup thread is 1956
> >[1948] GLOBAL_FUNCTION_TABLE is 4226120
> >[1948] in HttpExtensionProc thread 1956, CG(function_table) is
> 4226120
> >[1948] in HttpExtensionProc thread 1520, CG(function_table) is
> 18834536
> >[1948] in HttpExtensionProc thread 920, CG(function_table) is
> 18838912
> >[1948] in HttpExtensionProc thread 1956, CG(function_table) is
> 4226120
> >[1948] in HttpExtensionProc thread 1256, CG(function_table) is
> 19250808
> >[1948] in HttpExtensionProc thread 920, CG(function_table) is
> 18838912
> >[1948] in HttpExtensionProc thread 1956, CG(function_table) is
> 4226120
> >
> >Notice that the initial thread (1956) appears to continue to use
> >GLOBAL_FUNCTION_TABLE as it's own CG(function_table). I'm reporting
> >the GLOBAL_FUNCTION_TABLE value from within zend_startup() - is
> there
> >some point later in the code that makes it okay that this is the
> same
> >value that I get for a CG(function_table) later?
__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
