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

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, unlike most things, thread safety is difficult to obtain and very difficult to retain. So the 'every commit' statement is not bogus at all. It's easier to screw thread safety than just about anything else :) I wrote TSRM and made most of PHP thread safe, and I can tell you it was a bitch to stabilize, and 4.5 years later the job is still not completely done. When Shane started pushing towards FastCGI I initially resented the idea, but after a while he convinced me. I fail to find any disadvantages to FastCGI, and it comes with the great advantage of cross-process isolation. 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. Zeev At 22:35 25/08/2005, John Coggeshall wrote:

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. Having a means by which to identify and keep track of what extensions are considered "thread safe" is the only way to take a reasonable step forward on this issue. Saying TS of an ext could change with every commit is a bogus argument (anything can), and although it's reasonable to say there is a slight speed loss to PHP itself when operating in threaded mode we are simply supporting the technology not recommending it. On Thu, 2005-08-25 at 09:17 +0200, 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? best regards marcus Thursday, August 25, 2005, 1:28:49 AM, you wrote:

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 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 produce an error.

Not to hijack the topic, but if we are going to do something like this why not also provide these sorts of flags for things like

extensions and

thread safety?

Even though a change in an external lib or a commit in our source might change this - i see those cases very rarly and typically detected by the maintainers easily. Our code is threadsafe and most libs are, too. The other thing is the advantage and that is very big to my guesses since it would allow us to go with the faster apache way finally. So i like this idea pretty much.