Newsgroups: php.cvs,php.internals
Path: news.php.net
Xref: news.php.net php.cvs:81843 php.internals:77415
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
Message-ID: <35865ab5a49aa7711727174e173d0723.squirrel@webmail.klapt.com>
Date: Sun, 21 Sep 2014 19:19:29 +0200
To: "Anatol Belski" <ab@php.net>
Cc: "Dmitry Stogov" <dmitry@zend.com>,
 "Nikita Popov" <nikita.ppv@gmail.com>,
 php-cvs@lists.php.net,
 internals@lists.php.net,
 "Pierre Joye" <pierre.php@gmail.com>
User-Agent: SquirrelMail/1.5.2 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Re: [PHP-CVS] com php-src: fix CG(empty_string) init
 in ZTS: Zend/zend.c
From: anatol.php@belski.net ("Anatol Belski")

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