Re: TSRM changes broke windows compile
| From: | Rasmus Lerdorf | Date: | Fri, 25 May 2007 22:19:52 +0000 |
| Subject: | Re: TSRM changes broke windows compile | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-29779@lists.php.net to get a copy of this message | ||
Uwe Schindler wrote:
>>> It would be perhaps OK to make TSRM dependent on some global PHP
>> functions,
>>> but to make it depend on SAPI code that is only for webserver
>> interaction
>>> (!) and not related to TSRM (yes SAPI uses TSRM but not the other way
>> round)
>>> is not so good. And that only because of a not IO-related syscall!
>> It may not be IO, but on some systems fetching the time is actually
>> quite expensive. And SAPI isn't only for web server interaction. SAPI
>> is a general-purpose abstraction API that sits between PHP and anything
>> PHP talks to. CGI, CLI, and even embedded PHP are all SAPI-driven.
>> There is no way to use PHP without at least a stub SAPI layer.
>
> I know, I wanted only to put more pressure on that.
>
>>> A solution would be to make a function pointer inside TSRM that normally
>>> maps to time() or a TSRM-local wrapper of it. This would make TSRM not
>>> dependent on PHP. On the PHP part in SAPI startup there could optionally
>> be
>>> a redirect of the pointer to SAPI's get_request_time() implementation.
>> That could be done, yes. I'm just not sure it is worth the complexity.
>> TSRM is obviously a PHP-specific thing and it is already somewhat
>> SAPI-dependant even without this. The THREAD_T and MUTEX_T definitions
>> change based on the chosen SAPI.
>
> 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
So I don't see how this is no longer the case.
-Rasmus