Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65470
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <51086022.2060607@sugarcrm.com>
References: <d0d4398d8ad51ffa330d9d960bcd91a5@mail.gmail.com>
	<CAEZPtU7Pass+ogTJy5iBQpHARdNycXw8aMWxi=MkvZENw=hiwg@mail.gmail.com>
	<51086022.2060607@sugarcrm.com>
Date: Wed, 30 Jan 2013 07:05:50 +0100
Message-ID: <CAEZPtU4MuvY=paLWs0bJ5=r6EmyUPMp14iRP3jTvY=W6dOYfBA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Zeev Suraski <zeev@zend.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] ZTS - why are you using it?
From: pierre.php@gmail.com (Pierre Joye)

On Wed, Jan 30, 2013 at 12:49 AM, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
> Hi!
>
>> There are situations where FPM/FCGI are not appropriate, or the server
>> used does not support NTS (Apache windows for example, when fcgi is
>> not an option).
>
> Why Apache can't use FCGI? There's no proper driver os something in
> Apache architecture prevents it from using FCGI?

No, more by choice (out of the developer control).

>> No. My idea is to replace it with LTS (thread local storage) which
>> drastically reduce the thread safety issues due to its exact nature,
>
> I'm not sure it will. Our threading issues mainly related to libraries
> using global context and either not protecting it at all (e.g. ICU uses
> - or at least did couple of years ago - some global variables as caches
> which are locale-dependent, and once these cache vars are set, it's
> almost impossible to change and it leads to context leaking between
> threads) or protecting it improperly so that we get race conditions or
> crashes. Moving our data to LTS would make our part faster but won't
> make these libraries work better.

I did not check latest ICU code base but we never had any issues in
intl in ZTS. However you are right, since 5.3.0 most TS issues were in
libs, on windows I fixed a couple by patching the libraries when
possible (the oss ones).


>> The other main reason from my side to keep ZTS is Windows. Windows
>> cannot perform well using process based SAPI. It won't match linux as
>
> I don't see why. With proper prefork model, cost of process creation
> does not matter too much, and I've seen decent performance results with
> FCGI.

I never said fcgi performs badly. What I say is that Windows design is
not process based, none of the hiperformence tools available on this
platform is based on threads (AD, IIS, asp.net, etc.).

> Actually, IIRC, performance hit from ZTS is more than performance
> hit from multiprocess model. There are other things that make windows
> performance lag (Unicode APIs and filesystem being one of the factors,
> for example) but I do not think process model is a major factor here.

Filesystem is getting better, it is already better in 5.3.0+ and will
be a bit better in 5.5.0 (if I got the time to do it :/). We do not
use the unicode API yet (for IO or FS), so no real impact yet but a
few functions that still have to use it in some libs or in core.

>> promising, given that it is still only a proof of concepts. Having an
>> ISAPI also allows a tighter integration to IIS8 (pipelines, auths,
>> scripting, etc.), which is not possible to do now using fastcgi (no
>> direct access but using RMI or the IIS shell, but horrible, in all
>> possible ways).
>
> This is true, however I am not convinced it should be in PHP as opposed
> to separate user modules... If you'd want to run PHP code in IIS
> pipeline, I imagine performance-wise it would be expensive

To bring zts in line with NTS in term of performance is possible, look
at Arnaud's 1st draft for a TLS support in php:

https://wiki.php.net/rfc/tls

> - setting up
> PHP request is not a cheap thing, compared to what auth stage usually does.

The IIS pipeline architecture allows much more than only auth, much more.

Let me repeat it a last time, I do think that giving up on ZTS
altogether is a very bad idea, to say it in a nice way. That's the
kind of choice that will shoot at us back very soon. I agree that it
adds some work, but 99% of us do not care but there are solutions to
ease the developer work and reduce the wtf factors. TLS is one of
them.


Cheers,
--
Pierre

@pierrejoye