Re: Unicode-compatible extensions (was Re: [PHP-DEV] type hinting throwing a fatal error)

From: Date: Fri, 26 Aug 2005 00:34:20 +0000
Subject: Re: Unicode-compatible extensions (was Re: [PHP-DEV] type hinting throwing a fatal error)
References: 1 2 3 4 5 6 7 8 9 10  Groups: php.internals 
Request: Send a blank email to internals+get-18458@lists.php.net to get a copy of this message
In some environments you *need* to run a zts enabled PHP.
People that run in those environments can heed the warnings about
potential stability issues, evaluate them, and decide whether it makes
sense for their application.

I don't see any compelling need to rip out a feature that is essential
for some platforms, just because it might not work so well on others.

--Wez.



On 8/25/05, John Coggeshall <john@coggeshall.org> wrote:
> On Thu, 2005-08-25 at 23:09 +0300, Zeev Suraski wrote:
> > There are almost no advantages to multithreaded PHP.  There are
> > disadvantages (the reduced stability is inherent;  no matter how good PHP
> > gets, multi-process deployments are by definition more
> > robust).  Performance is slightly degraded too, so why bother?
> 
> > I'm not saying we should get rid of the thread safe mode, but frankly, the
> > main reason is that it doesn't bother anybody and is useful for some
> > people.  Not because I think we'll ever quite get there.
> 
> Why not just get rid of it then? (i.e. something as simple as just not
> allowing it to be turned on at all) and instead provide a nice automated
> fastCGI install in its place? I seem to recall seeing something
> somewhere along the line about fastCGI being faster then prefork Apache
> as well (there was a patch?), if I am remembering correctly wouldn't it
> make sense to make that the default installation method across the
> board? At the very least it makes sense for threaded environments
> obviously...
> 
> John
> 
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
>


Thread (125 messages)

« previous php.internals (#18458) next »