Uwe Schindler wrote: >>> An extra syscall on every file open isn't exactly miniscule. >> It's a syscall not related to any filesystem or I/O so it can't be that >> bad. And we managed to live with it so far. >> >>> Edin also just built Windows binaries without problems. Why did it work >>> for him? >> I have no idea. But it is obvious that it doesn't work in all >> environments, and it worked before just fine. Anyway, both breaking >> build _and_ intoducing dependency of TSRM on PHP and both in a minor >> version _and_ both without discussing it doesn't look like very good >> idea to me. I would propose: >> 1. Revert it for 5.2.3 >> 2. Discuss if we want TSRM/Zend be now usable only with PHP >> 3. Discuss if we really need this patch and if so can we do it without >> breaking (2) > > As I was involved today this morning also with startup failures because of > this change, I came to the following: > > 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. > 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. 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. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
