Uwe Schindler wrote:
> Hi Rasmus,
>
>>> This is no longer the case. E.g. when compiling the module for the NSAPI
>>> webserver (Sun Java System Webserver) there should be a global define
>> like
>>> -DNSAPI in the makefiles (not only for nsapi.c) which is not. Because of
>>> that all SAPIs do not have an effect on the thread implementation. When
>>> compiling PHP with ZTS you always get an .o file that links to pthreads.
>>> This must be the case, because without that it would not be possible to
>> link
>>> a CLI PHP in parallel to the webserver specific SAPI.
>> That's simply not the case. Look at the nsapi code:
>>
>> #define NSAPI 1
>>
>> #ifdef HAVE_CONFIG_H
>> #include "config.h"
>> #endif
>>
>> #include "php.h"
>> #include "php_variables.h"
>> #include "ext/standard/info.h"
>> #include "php_ini.h"
>> #include "php_globals.h"
>> #include "SAPI.h"
>> #include "php_main.h"
>> #include "php_version.h"
>> #include "TSRM.h"
>> #include "ext/standard/php_standard.h"
>> #include <sys/types.h>
>> #include <sys/stat.h>
>>
>> It defines NSAPI before including TSRM.h and in TSRM.h we have:
>>
>> #elif defined(NSAPI)
>> # define THREAD_T SYS_THREAD
>> # define MUTEX_T CRITICAL
>
> Butt his is only for nsapi.c. All other PHP modules and the core itself do
> not know anything about NSAPI. This leads to the fact that if the webservers
> thread implementation is incompatible to the system default the build .o of
> nsapi.c is not compatible to the other .o files.
>
> This happens here:
> When compiling TSRM.c with the lines in it:
>
> TSRM_API THREAD_T tsrm_thread_id(void)
> {
> #ifdef TSRM_WIN32
> return GetCurrentThreadId();
> #elif defined(GNUPTH)
> return pth_self();
> #elif defined(PTHREADS)
> return pthread_self();
> #elif defined(NSAPI)
> return systhread_current();
> #elif defined(PI3WEB)
> return PIThread_getCurrent();
> #elif defined(TSRM_ST)
> return st_thread_self();
> #elif defined(BETHREADS)
> return find_thread(NULL);
> #endif
> }
>
> NSAPI is *not* defined. This is not a problem because the
> systhread_current()-NSAPI function internally calls pthread_self() but only
> if the webserver runs in pthreads.
> On AIX (or was it HP-UX??? I should look into my bug reports) the webserver
> runs in another thread implementation. This leads to crashes in the
> webserver because PHP uses pthreads (because of TSRM.c) and all the
> webserver another one. In the worst case
> #define THREAD_T SYS_THREAD
> is also incompatible in size and structure and misbehaves between SAPI code
> (with define) and PHP (without define).
Right I see what you mean. But to me this only illustrates why
environmental side-effects like this are an incredibly bad idea. They
tend to be forgotten, which appears to be the case here, and they are
hard to debug. If the SAPI affects how TSRM does things, this should be
an explicit dependency either by making TSRM always include the SAPI
environment so no matter where TSRM is called from it behaves the same,
or we move to a system where on sapi startup we register function
pointers with TSRM both for the locking. Either solution will solve the
time() thing as well. I don't mind removing the time() call for this
release, but I think we clearly need to fix this loose broken coupling
we have now.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
