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
AGProblem is that some extensions that don't support Unicode will
AGstill work. Extensions like gd might almost work out of the box.
We can go over standard extensions and rubber-stamp ones that we think
do not need changes. As for PECL/external extensions, I think maintainers
should do that.
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
JC Maybe we can give extensions a way to indicate that they're Unicode
JC compatible, and assume they're not if they don't. Non-compatible
JC extensions will not be loaded and produce an error.
JC
JCNot to hijack the topic, but if we are going to do something like this
JCwhy not also provide
On Wed, 2005-08-24 at 18:30 +0300, Stanislav Malyshev wrote:
JC Maybe we can give extensions a way to indicate that they're Unicode
JC compatible, and assume they're not if they don't. Non-compatible
JC extensions will not be loaded and produce an error.
JC
JCNot to hijack the topic, but
JCThat's basically what I'm saying, I guess maybe this is a PHP 6.0
JCwishlist sort of thing -- I'd like to see PHP when operating in thread
JCsafety mode be very unhappy loading extensions not flagged thread
JCsafe.
Ah, now I see, so you propose along with compiled in TS to have
actually
On Wed, 2005-08-24 at 18:47 +0300, Stanislav Malyshev wrote:
Ah, now I see, so you propose along with compiled in TS to have
actually works in TS flag. Only problem here is that extension author
may probably not know if it works in TS - TS support is much more
complicated than unicode
John Coggeshall wrote:
On Wed, 2005-08-24 at 18:47 +0300, Stanislav Malyshev wrote:
Ah, now I see, so you propose along with compiled in TS to have
actually works in TS flag. Only problem here is that extension author
may probably not know if it works in TS - TS support is much more
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
20 matches
Mail list logo
