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

From: Date: Thu, 25 Aug 2005 07:17:02 +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 11 12 13 14 15 16 17 18 19 20  Groups: php.internals 
Request: Send a blank email to internals+get-18396@lists.php.net to get a copy of this message
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.

« previous php.internals (#18396) next »