Stanislav Malyshev wrote: >> 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. > > There is, however, a way to use Zend Engine/TSRM. With this change, Zend > Engine/TSRM could no longer be used without PHP. And all this for some > time() patch... > >> That could be done, yes. I'm just not sure it is worth the complexity. > > I, for one, don't really understand what all this filesystem stuff does > in TSRM anyway. It's not like it has anything to do with thread safety. > Maybe it should just be moved to PHP and Zend Engine should talk to it > via handlers? > >> 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. It doesn't explicitly include SAPI.h > > No, it's not SAPI-dependent. It's environment-dependent, which is > entirely different thing. It can be configured, built and used without PHP.
Well, by that logic you would be fine with: #define TIME_CALL sapi_get_request_time(TSRMLS_C) and in tsrm_virtual_cwd.c #ifndef TIME_CALL define TIME_CALL time(0) #endif ... t = CWDG(realpath_cache_ttl)?TIME_CALL:0; that makes it environment-dependent instead of explicitly-dependent, and also way harder to debug. Environmental side-effects like that are nasty. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
