> > 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. Because of that limitation for example the Sun Webservers on (SJSWS) on AIX crash on startup (there are a lot of bug reports about that, but I cannot help because I have no access to such a system). I only know that SJSWS is implemented on AIX not with POSIX threads. And on Solaris the webservers also crash when you switch to an alternative "kernel" (do not know the exact name) thread implementation in the webserver. This is because the ifdefs in TSRM.h never apply specific to the SAPI implementation. > It doesn't explicitly include SAPI.h > because it relies on the side-effect of TSRM.h being included after the > SAPI stuff. I don't see an explicit include as really changing things > very much. It was just a suggestion. But it should not hard to implement. Uwe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
