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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
