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.
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 does. Now it's impossible to use TSRM without PHP and it also doesn't build on Windows.
-- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
