Stanislav Malyshev wrote: >> 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; > > Theoretically yes, that could work, but: > >> >> that makes it environment-dependent instead of explicitly-dependent, and >> also way harder to debug. >> >> Environmental side-effects like that are nasty. > > Exactly. So I'd propose to think how to do it right - not excluding > taking the whole cache & system-dependant filesystem things out of TSRM. > They do not really related to the rest of TSRM and could be abstracted > same way as open/output/error functions are abstracted.
But that doesn't fix the broken side-effects we already have in the locking code depending on defines in the individuals SAPIs which Uwe showed isn't working either. And if we exclude locking from TSRM as well, what is left? We either need to tie TSRM to SAPI or we need to add the ability for the SAPIs to register their various semantics with TSRM. The filesystem code is in TSRM because of the virtual working directory stuff. That is thread-related in that each thread needs it own working directory. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
