Fair enough Wez :)
On Thu, 2005-08-25 at 20:34 -0400, Wez Furlong wrote:
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
At 03:34 26/08/2005, Wez Furlong wrote:
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
At 10:17 25/08/2005, Marcus Boerger wrote:
Hello Andi,
wow, now that makes me wonder if you perhaps also know a reason for?
I mean in theory it should be faster shouldn't it? Or is the problem
that we far to often use TRSMLS_FETCH() with all its disadvantages?
Whenever we touch a shared
I don't buy into the argument that we shouldn't start even trying to
solve the thread safety issues in PHP because of some arbitrary we
can't tell or it's faster not to do it sort of argument. Threads
aren't exactly an archaic or edge technology, and it's just stubborn of
us not to support them.
I generally disagree.
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?
And yes,
I don't think anyone was arguing that we should fix TS issues. We've
been doing that for ages (since the early days of PHP 4).
The question is wether there is much value in marking extensions as
thread-safe.
At 12:35 PM 8/25/2005, John Coggeshall wrote:
I don't buy into the argument that we
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
As Zeev stated it's additional thread-storage fetching and passing an
extra parameter. However, it's a marginal difference so I wouldn't
base my architectural decision on that. It was only regarding
performance decision. I wouldn't base my architecture decision solely
based on performance but
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
At 17:37 24/08/2005, Rasmus Lerdorf wrote:
Steph wrote:
Hi Rasmus,
Steph wrote:
If there's the capability to run PHP 6 without Unicode support, surely
there's no reason for extensions to lose back compatability when they're
updated...?
That's going to be tough. They will definitely lose
On Wed, 2005-08-24 at 17:41 +0300, Zeev Suraski wrote:
Maybe we can give extensions a way to indicate that they're Unicode
compatible, and assume they're not if they don't. Non-compatible
extensions will not be loaded and produce an error.
Not to hijack the topic, but if we are going to do
Hello John,
Wednesday, August 24, 2005, 5:22:07 PM, you wrote:
On Wed, 2005-08-24 at 17:41 +0300, Zeev Suraski wrote:
Maybe we can give extensions a way to indicate that they're Unicode
compatible, and assume they're not if they don't. Non-compatible
extensions will not be loaded and
Hello Zeev,
Wednesday, August 24, 2005, 4:41:25 PM, you wrote:
At 17:37 24/08/2005, Rasmus Lerdorf wrote:
Steph wrote:
Hi Rasmus,
Steph wrote:
If there's the capability to run PHP 6 without Unicode support, surely
there's no reason for extensions to lose back compatability when
Marcus,
You will most likely find that the faster Apache way with
thread-safe PHP is slower than the slower Apache way with
non-thread-safe PHP. And even FastCGI will be faster :)
Andi
At 12:25 PM 8/24/2005, Marcus Boerger wrote:
Hello John,
Wednesday, August 24, 2005, 5:22:07 PM, you
14 matches
Mail list logo
