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, that's different problem which I can't really tell about because I don't know enough NSAPI. Locking however is necessary for doing threading stuff, and realpaht cache is not really needed for that.
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.
Maybe, but if it's done I think it needs to be clean semantics, not just ad-hoc inserting calls from each other. Just as it's done in ZE.
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.
Each thread has its own globals for each module, but for other modules having globals is not the reason to put them into TSRM.
-- 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
