Re: Re: com php-src: fix CG(empty_string) init in ZTS: Zend/zend.c

Hi Dmitry, On Sat, September 20, 2014 09:58, Anatol Belski wrote: > Hi Dmitry, > > > On Fri, September 19, 2014 12:43, Dmitry Stogov wrote: > >> I know :) >> Interned strings in PHP5 were implemented as characters allocated in one >> single buffer. Adding new strings into this buffer from different >> threads would require synchronization (locks). >> >> In PHP7 this implementation was changed. So it's probably must be >> possible to use interned strings in ZTS now. If we use separate >> HashTables >> for interned strings in different threads we may share some common part >> of predefined interned strings and have new interned strings in each >> thread independently. I'm not sure if it'll work well with opcache, >> because it substitutes interned strings handling mechanism to use shared >> memory. May be it'll work out of the box. BTW: I'm not interested in >> implementing this myself. >> >> Also, if we really like ZTS, may be PHP7 is the time to switch to >> native TLS and remove all these TSRMLS macros. >> Even if it won't allow to run ZTS on some platforms, it won't be the end >> of the world, because ZTS is not really widely used now. I won't be >> able to work on it actively, but I may provide some help. >> >> Thanks. Dmitry. >> >> > maybe it'd make sense to do it the other way round. First get rid of > TSRM, > than look what is doable with interned strings? I'd be sure in the game, if > there are enough interested people to actively do that. > yesterday Joe pushed the approach on the TSRMLS_* removal subject http://git.php.net/?p=php-src.git;a=shortlog;h=refs/heads/native-tls While trying to port it for Windows, I see some design issues and have an idea how to solve it. The patch is relying on a few things which Visual Studio cannot handle. The first one: TSRM_API extern TSRM_TLS void *tsrm_ls_cache; but exporting the TSRM cache from a DLL won't work with VS. There it would look like __declspec(dllexport) extern __declspec(thread) void *tsrm_ls_cache; VS linker cannot share variables directly between DLL and EXE. Furthermore, even bigger issue could be with modules loaded on runtime. The second issue is that while ini entries are defined in static arrays, when they link to some SAPI or extension globals, they would have an id passed. That Id would be declared like __declspec(dllimport) ts_rsrc_id cli_server_globals_id; While passed to the ini entry by reference, it's still not a constant value. So VS refuses to initialize an ini entry with something not from the constant extent (AFAIK that's ok for C89). That's for the issues. How to solve them - after some research it looks like one can share thread data using getter/setter functions (using DLL_THREAD_ATTACH event in DllMain to initialize current thread data). That would probably require some more rewrites in the code. The main question, whether the negative impact because of having to do the extra function calls would make such porting senseless. The flow were like apache (or php) binary starts thread TSRM layer inits TLS data php inits globals / depend on TSRM layer extensions init/read globals / depend on TSRM layer That's just a basic idea yet. For the second issue - some similar approach. Instead of using &some_globals_id, one could replace it with a function pointer so then it can deliver the right location by thread. What do you think about my solution ideas? Maybe also there was some other approaches we didn't take in account yet? Depending on whether we can use the function calls, maybe it'd even make sense to make something like libtsrm to incapsulate all the TS features. Thanks Anatol