Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65489
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain zend.com does not designate 209.85.214.173 as permitted sender)
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>
	<CAEZPtU62F-n9=v+NLNMLuxV1bkHUXimzeqjs_cy0=nKMihB+Rw@mail.gmail.com>
	<5108743A.9090705@sugarcrm.com> <CAEZPtU6jSvf6Abu0micxx3wPWVBjv+VGv+zVx-Zr+obqX2M=uQ@mail.gmail.com>
In-Reply-To: <CAEZPtU6jSvf6Abu0micxx3wPWVBjv+VGv+zVx-Zr+obqX2M=uQ@mail.gmail.com>
MIME-Version: 1.0
Thread-Index: AQJJdUzE2iPwKiwvzciYvchG03LAWgHrKhe1AkgXmvEAyNLsagGCs/1aAVyIuMoBzi4ZIgKDM2kDlwle5JA=
Date: Wed, 30 Jan 2013 13:16:41 +0200
Message-ID: <4d977bab18152b2e86d968f4db9d12ef@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>, Stas Malyshev <smalyshev@sugarcrm.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: RE: [PHP-DEV] ZTS - why are you using it?
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: Pierre Joye [mailto:pierre.php@gmail.com]
> Sent: Wednesday, January 30, 2013 8:10 AM
> To: Stas Malyshev
> Cc: Zeev Suraski; PHP internals
> Subject: Re: [PHP-DEV] ZTS - why are you using it?
>
> On Wed, Jan 30, 2013 at 2:15 AM, Stas Malyshev <smalyshev@sugarcrm.com>
> wrote:
> > Hi!
> >
> >> Python, for example, is thread safe by default. Extensions developers
> >
> > Doesn't Python have global engine lock?
>
> Right, but they do not give up thread safety. See "Thread State and the
Global
> Interpreter Lock" in:
>
> http://docs.python.org/2/c-api/init.html

Pierre,

As Stas pointed out a global lock has very little to do with the topic of
discussion here.  What PHP is trying to do is *much* more ambitious, so
ambitious that at least I concluded it's not an achievable goal.  This has
nothing to do with laziness, much like deprecating safe_mode wasn't about
laziness - it was about facing reality.  The Python approach is
exceptionally lazy (in software development that's often a Good Thing),
and can be implemented very quickly if we wanted to.  It wouldn't help you
one bit with your use cases, though.

> The TS model in php should be redesigned in the next major version,
instead of
> simply giving it up.

I don't mind that we redesign TS for the next version, with two key
issues:

1.  I'm not sure that relying on TLS (beyond what we already do on TSRM
today) is feasible.  That was the na=C4=8Fve approach that I first tried ba=
ck
in 1999 and ended up ditching since it wasn't suitable.  The two main ones
are:  [a] limited TLS space (we have *lots* of globals) [b] Inability to
access globals from another image (e.g.., you won't be able to access
sapi_globals which belong to php5.dll from mysqli.dll).  Point [b] is
mentioned in the RFC that you referred to.  Point [a] might have been
solved over the course of the last decade.  TSRM wasn't designed for fun,
it was there to solve real problems that TLS did not solve.

2. I think it's not very good use of our time.  Based on what I heard in
this thread, I would give up right here and now on the goal of having PHP
run in-process in multithreaded web server.  The pros pale in comparison
to the cons.  I would *not* remove ZTS - this was never the point of this
thread - but I would recalibrate people's expectations about it.  It
sounds as if it could be useful for advanced 'I know what I'm doing' use
cases like long-running threaded processes, and may be useful for the
future if we ever want to support threads within a single request - but
that's about it.

Based on the feedback on this thread, I think we should instruct users
that using thread-safe versions of PHP is slower, and that actually
putting thread-safe PHP inside a multithreaded server is not a very
reliable solution.  We should recommend FastCGI/fpm instead.  We should do
that tomorrow morning (figuratively speaking).

Zeev