> -----Original Message----- > From: Dmitry Stogov <dmi...@zend.com> > Sent: Thursday, February 14, 2019 11:21 PM > To: Anatol Belski <a...@php.net>; Nikita Popov <nikita....@gmail.com> > Cc: Joe Watkins <krak...@gmail.com>; Bob Weinand <bwo...@php.net>; > Nikita Popov <ni...@php.net>; z...@php.net; PHP internals > <internals@lists.php.net> > Subject: Re: ZTS improvement idea > > > > On 2/14/19 8:55 PM, Anatol Belski wrote: > > Hi Nikita, > > > >> -----Original Message----- > >> From: Nikita Popov <nikita....@gmail.com> > >> Sent: Wednesday, February 13, 2019 1:02 AM > >> To: Dmitry Stogov <dmi...@zend.com> > >> Cc: Joe Watkins <krak...@gmail.com>; Bob Weinand > <bwo...@php.net>; > >> Nikita Popov <ni...@php.net>; Anatol Belski (a...@php.net) > >> <a...@php.net>; z...@php.net; PHP internals <internals@lists.php.net> > >> Subject: Re: ZTS improvement idea > >> > >> On Wed, Feb 13, 2019 at 9:26 AM Dmitry Stogov <dmi...@zend.com > >> <mailto:dmi...@zend.com> > 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 :) > > In two words, if we make executor_glabal to be "__thread", we will get > troubles accessing it from DSO extensions. Right? > > Thanks. Dmitry. > Exactly. Plus, it might introduce issues with C++ compatibility.
Thanks Anatol
