Newsgroups: php.cvs,php.internals
Path: news.php.net
Xref: news.php.net php.cvs:81850 php.internals:77422
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <35865ab5a49aa7711727174e173d0723.squirrel@webmail.klapt.com>
References: <35865ab5a49aa7711727174e173d0723.squirrel@webmail.klapt.com>
Date: Mon, 22 Sep 2014 10:43:10 +0400
Message-ID: <CA+9eiLu1fsRFMvP3B0T+kELjKxyPRt1rFEuGzcOZvdXF-F87Sg@mail.gmail.com>
To: Anatol Belski <anatol.php@belski.net>, Joe Watkins <krakjoe@php.net>
Cc: Anatol Belski <ab@php.net>, Nikita Popov <nikita.ppv@gmail.com>, 
	"php-cvs@lists.php.net" <php-cvs@lists.php.net>, PHP Internals <internals@lists.php.net>, 
	Pierre Joye <pierre.php@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b5d28d8a5c64a0503a1c392
Subject: Re: [PHP-DEV] Re: [PHP-CVS] com php-src: fix CG(empty_string) init in
 ZTS: Zend/zend.c
From: dmitry@zend.com (Dmitry Stogov)

--047d7b5d28d8a5c64a0503a1c392
Content-Type: text/plain; charset=UTF-8

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.


On Sun, Sep 21, 2014 at 9:19 PM, Anatol Belski <anatol.php@belski.net>
wrote:

> 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
>
>
>
>
>
>

--047d7b5d28d8a5c64a0503a1c392--