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
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 appli
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
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 a
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 degra
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 sh
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, unlik
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
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 reso
AG>>Problem is that some extensions that don't "support" Unicode will
AG>>still 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
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?
best regards
marcus
Thursday, August 25, 2005, 1:28:49 AM, you wrote:
> Mar
One more thing, don't take this as thread safety isn't important. The
better we can make PHP's thread-safety the better. But I won't run it
on my Apache :)
At 12:25 PM 8/24/2005, Marcus Boerger wrote:
Hello John,
Wednesday, August 24, 2005, 5:22:07 PM, you wrote:
> On Wed, 2005-08-24 at 17:
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 wr
Problem is that some extensions that don't "support" Unicode will
still work. Extensions like gd might "almost" work out of the box.
At 08:36 AM 8/24/2005, John Coggeshall wrote:
On Wed, 2005-08-24 at 18:30 +0300, Stanislav Malyshev wrote:
> JC>>> Maybe we can give extensions a way to indicate
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
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 a
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 mor
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 unicod
JC>>That's basically what I'm saying, I guess maybe this is a PHP 6.0
JC>>wishlist sort of thing -- I'd like to see PHP when operating in thread
JC>>safety mode be very unhappy loading extensions not flagged thread
JC>>safe.
Ah, now I see, so you propose along with "compiled in TS" to have
"ac
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>>
> JC>>Not to hijack
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>>
JC>>Not to hijack the topic, but if we are going to do something like this
JC>>why not a
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
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
23 matches
Mail list logo
