Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65497
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain tobin.nl designates 208.97.132.119 as permitted sender)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; c=nofws; d=tobin.nl; h=subject:mime-version
	:content-type:from:in-reply-to:date:cc:content-transfer-encoding
	:message-id:references:to; q=dns; s=tobin.nl; b=JuY2naC9o7OrU72S
	uUw3heEkeHxJ2U0u/AulpZw9rwn6hZKEw0g/c9C6Qy8gUrGJjCtfkQmG8mHdH9OQ
	5W/dDnOYwpRwzA4+4sUOHGg5rQbzU2vccTLfr16NQO9+XxjHSJJoSsXfJNNgQTMu
	wsB4sQsSKWSwPRm6i2m4qWttdDA=
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <4d977bab18152b2e86d968f4db9d12ef@mail.gmail.com>
Date: Wed, 30 Jan 2013 13:28:57 +0100
Cc: Pierre Joye <pierre.php@gmail.com>,
 Stas Malyshev <smalyshev@sugarcrm.com>,
 PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <9DB107EF-A5CE-4CF5-84A1-7E2D733B4089@tobin.nl>
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> <4d977bab18152b2e86d968f4db9d12ef@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Subject: Re: [PHP-DEV] ZTS - why are you using it?
From: bas@tobin.nl (Bas van Beek)

Hi Guys,

As a heavy user of ZTS in multi threaded C/C++ applications, here are my =
$0.02.

Removing ZTS would be a bad idea for all those custom multi-threaded =
applications out there that allow some form of internal/embedded PHP =
scripting. These applications are not web-servers but do make use of =
threads for reasons of their own. Building a FastCGI set-up would be out =
of the question if these apps are deployed customer / client side and =
need concurrent PHP script runs.

> 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
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20


This makes a lot of sense, I see where FastCGI/fpm is the best solution =
for the majority of users of PHP which deploy large scale web =
applications. The tone in this conversation looked like ZTS had no place =
in the PHP future. I think it does, but maybe not for the regular web =
server / web application use case. For custom applications with embedded =
PHP, I see it making more and more sense as a lot of native applications =
need to interface with web services and often SDK's for these services =
are either not available or tedious to use for native application =
development. Being able to use the PHP SDK's and quickly build conduits =
between custom apps and services using PHP is very beneficial. =
Developers of these kind of apps are well aware of the potential =
pitfalls in using threads and potential non TS libraries as long as =
documentation is clear about it.

My biggest worry is when we signal that ZTS is a relic or not important =
enough to support in extensions we end up with developers building =
extensions not trying to be ZTS compatible even if they could be made =
thread safe easily. For the majority of extensions it's a simple =
question of adding the TSRM macros. If the underlying library doesn't =
support it or it would impact performance too much, I would at least =
want to know that the extension is not thread safe so I can leave it =
aside and come up with another solution.



Bas van Beek=