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 :)
Thanks Anatol
