Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65361
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1359459921.3916.105.camel@guybrush>
References: <d0d4398d8ad51ffa330d9d960bcd91a5@mail.gmail.com>
	<CAEZPtU7Pass+ogTJy5iBQpHARdNycXw8aMWxi=MkvZENw=hiwg@mail.gmail.com>
	<e8cf5bb937155b161076584852de6753@mail.gmail.com>
	<CAEZPtU4_8Eh2j6JkSqY883jM--_i+b=PABbdrxKFqPaQGht9Bg@mail.gmail.com>
	<1359459921.3916.105.camel@guybrush>
Date: Tue, 29 Jan 2013 12:49:11 +0100
Message-ID: <CAEZPtU7wP0O4rfeSfQV9Ct6wGWSy2kgUCWxEybFY7-Bx9tLoqA@mail.gmail.com>
To: =?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>
Cc: Zeev Suraski <zeev@zend.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] ZTS - why are you using it?
From: pierre.php@gmail.com (Pierre Joye)

hi,

On Tue, Jan 29, 2013 at 12:45 PM, Johannes Schl=FCter
<johannes@schlueters.de> wrote:
> On Tue, 2013-01-29 at 12:15 +0100, Pierre Joye wrote:
>>
>> Laziness and design mistake. Everything on windows (AD,IIS, asp.net,
>> etc)
>> uses thread.
>
> Well, most other things don't create "shared-nothing" environments like
> PHP does. ASP, not only due to the Application object, for instance
> isn't shared-nothing like PHP but sharing state. So what we're doing,
> basically, is emulate a separation of threads, similar to what an
> operating system should do with processes.
>
> Of course an opcode cache isn't shred-nothing either, and maybe sharing
> opcodes within a process is faster than doing this in shared memory.

It is inter process sharing and is very expensive, nothing to compare
with shared memory within a single process, accross many threads.

>> Miss the rest of my mail or? Current implementation is outdated and
>> slow.
>
> That is true. Many modern compilers and environments provide  better
> support for thread local storages ....

Exactly, or more exactly CRTs (libc, crt and the likes)>

> What I see is that TSRM brings a lot of complexity and introduces risk
> of bugs in there as many developers don't think about. Most of us are
> focused on the nice and simple world of single-threaded computing. And I
> assume that we can still find quite some threading bugs when going on a
> hunt for them ... so besides of pure executable performance there is
> also the cost of developer power for (proper) maintenance ...

The amount of bugs is rather low. We do test in TS and TS on a daily
basis. The last extension causing more critical issues was mysql, we
have discussed these bugs for a long time.


However let me state my point clear: Giving up on thread safety would
be a mistake as big as safemode and other insane choices we made. That
does mean we have to keep going with the current state but we must
keep it. Other languages support it because most of them are thread
safe by design and allows extensions to rely on that.

Cheers,
--
Pierre

@pierrejoye