Hi Nikita, > -----Original Message----- > From: Nikita Popov <[email protected]> > Sent: Wednesday, February 13, 2019 1:02 AM > To: Dmitry Stogov <[email protected]> > Cc: Joe Watkins <[email protected]>; Bob Weinand <[email protected]>; > Nikita Popov <[email protected]>; Anatol Belski ([email protected]) <[email protected]>; > [email protected]; PHP internals <[email protected]> > Subject: Re: ZTS improvement idea > > On Wed, Feb 13, 2019 at 9:26 AM Dmitry Stogov <[email protected] > <mailto:[email protected]> > wrote: > > > Hi, > > > > > After JIT+ZTS related discussion with Joe and Bob, and some related > analyzes. > > I came to more or less formed design idea and described it at > https://wiki.php.net/zts-improvement > > This is not an RFC and I'm not sure, if I like to implement TSRM > changes myself now. > > > > > Comments are welcome. > > > Hi Dmitry, > > Thanks for looking into this issue. As a possible alternative I would like to > suggest the use of ZEND_TLS (__thread) for the EG/CG/BG etc globals on > Linux (on Windows this is not possible due to DLL linkage restrictions). > __thread generates very good code (single load over %fs segment with > constant address) if the global is defined and used in an executable. I'm not > sure what kind of code it generates when TLS is declared in an executable > and used in a shared object, but as direct access from extensions to the > engine globals shouldn't be common, it's probably okay even if it uses > __tls_get_addr. > TLS data available across shared objects is a GNU extension and AFAIK there's a lot of black magic behind it. Thread local storage should be indeed local to some scope, be it a function or a binary unit, as per design. Like for C++11 as well, it's thread_local we currently use. It'd hurt the portability and likely introduce issues in the future, as it might affect any non GNU systems which we rarely test. Otherwise, of course it would be easy to say, we add ZEND_TLS to the definition, and be good :)
Thanks Anatol
