Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65362
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAPgLKii7GijPUqajVt7+jY9GSYW_rbLfMJLW43xO2V6W3c5kcQ@mail.gmail.com>
References: <d0d4398d8ad51ffa330d9d960bcd91a5@mail.gmail.com>
	<CAEZPtU7Pass+ogTJy5iBQpHARdNycXw8aMWxi=MkvZENw=hiwg@mail.gmail.com>
	<e8cf5bb937155b161076584852de6753@mail.gmail.com>
	<CAEZPtU4_8Eh2j6JkSqY883jM--_i+b=PABbdrxKFqPaQGht9Bg@mail.gmail.com>
	<CAPgLKii7GijPUqajVt7+jY9GSYW_rbLfMJLW43xO2V6W3c5kcQ@mail.gmail.com>
Date: Tue, 29 Jan 2013 12:56:45 +0100
Message-ID: <CAEZPtU62F-n9=v+NLNMLuxV1bkHUXimzeqjs_cy0=nKMihB+Rw@mail.gmail.com>
To: 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 Tue, Jan 29, 2013 at 12:36 PM, Zeev Suraski <zeev@zend.com> wrote:

>> Laziness and design mistake. Everything on windows (AD,IIS, asp.net, etc)
>> uses thread.
>>
>> And no, nuts is not faster. I am not talking about PHP zts, but in
>> general.
>
>
> Of course everything that is Windows native uses threads, but I don't
> believe any language that is single-threaded on other platforms - has a
> thread safe version for Windows.

Python, for example, is thread safe by default. Extensions developers
can rely on its APIs to write TS code. Our core is designed in a way
that it is painful to have to deal with two code bases. That's what
causes troubles, not really something else.

> I disagree that laziness and design mistakes are what makes ZTS slower.
> It's slower by design, since instead of relying on operating system
> isolation - you have to emulate it yourself in userland code.

It was and still is a lazy and design mistake to have focused on
FastCGI to support PHP on IIS more easily, while everything else in
this stack uses what the whole OS stack does.


> Contrary to popular belief FastCGI actually works very very well on Windows,
> and has substantial advantages over using a server module - even on Linux
> (it's no coincidence that there are hoards of users migrating from Apache to
> nginx, where a server module isn't even an option - and they're seeing
> better performance, not worse).

I never said that FastCGI does not work well. But that doing so will
never allow us to reach the performance we could get using a more
suited implementation.

About nginx vs Apache, I'm also quite sure that we can get an Apache
SAPI module performing as good as nging with FPM. It is only almost
impossible with the current implementation of PHP, we both know that.
We have seen examples in the past already where well optimized php and
apache were as fast as lighttpd (back then) with a correct setup.

Again, giving up on thread safety is a major mistake.

Cheers,
--
Pierre

@pierrejoye