Re: Re: com php-src: fix CG(empty_string) init in ZTS: Zend/zend.c
| From: | Anatol Belski | Date: | Fri, 26 Sep 2014 20:59:58 +0000 |
| Subject: | Re: Re: com php-src: fix CG(empty_string) init in ZTS: Zend/zend.c | ||
| References: | 1 2 | Groups: | php.cvs php.internals |
| Request: | Send a blank email to internals+get-77686@lists.php.net to get a copy of this message | ||
Hi Dmitry,
On Mon, September 22, 2014 08:43, Dmitry Stogov wrote:
> Hi Anatol,
>
>
> I didn't completely get your ideas, but if tsrm_ls_cache can't be
> exported on Windows directly, can we have a copy of tsrm_ls_cache in each
> DLL/EXE
> and initialize it once?
>
> Thanks. Dmitry.
>
Joe and me was working on this and there is a worky version now. Generally
it suffers from some issues already present in master, but in all things
together it's a worky crossplatform approach. Please look up the
native-tls branch.
For the current variant I used the idea from the original RFC, but removed
exporting the TSRM cache through a __thread variable as it's not portable.
I've also removed the offset logic from the RFC patch, as that brought
additional hard to find bugs especially into the current unstable version.
I don't think it's necessary to copy the arbitrary globals structs in
every ext, further more i think it's not easy possible without some big
overhead. However even with the current native-tls branch I'm able to run
wordpress, symfony, ab -c 8 -n 2048 pass also with multiple calls. Still,
some Apache bugs are already reported against master, I also repro some
others, mostly arbitrary shutdown crashes in Apache (so TS version). So as
they're in master, they're for sure in native-tls.
PHP happens to always have used TLS, however the pointer was passed
directly to the functions. In TSRM.c, that's tsrm_tls_get/tsrm_tls_set.
Now, a function wrapper is used to fetch the TLS cache directly in the
TSRMG macro. This makes the whole slowlier, but allows to get rid of the
TSRMLS_* macros. The big question is to optimize the function call to
speedup the whole. Maybe one can speedup it saving a tsrm ls cache pointer
locally per extension or code area. ATM we're checking the functional
part, then one can proceed further with removing the TSRMLS_* macros. Any
speedup or improvement thoughts are welcome.
Possible directions of the further work after known bugs are fixed (in
master or in native-tls), some are mutually exclusive
- reimplement the offset logic instead of arrays for the globals structs
- share the tsrm cache pointer globally to some scope, like extension or sapi
- remove the linked lists logic and use TLS explicitly
- improve locking
Thanks
Anatol