On Tue, 14 Sep 2004, Andrey Hristov wrote:
> Both points make sense. Just name the configure option well and put big warnings
> there
> that when the option is switched on this _may_ lead to crashing applications.
Nothing will crash, it's just that include_once might fail if you're
using two dif
On Tue, 14 Sep 2004, Andi Gutmans wrote:
> At 10:52 AM 9/14/2004 -0700, Rasmus Lerdorf wrote:
> >The patch doesn't just address realpath though. We have a number of other
> >redundant/non-essential syscalls in the streams code, for example. And
> >the realpath cache is still heavier than not wor
On Tue, 14 Sep 2004, Andi Gutmans wrote:
> a) I will try and send internals@ an updated version of the realpath()
> cache in the next few days. This should give a lot of bang for the buck
> because realpath() is probably the suckiest system call in the startup.
> b) Maybe Wez & Sara can take one m
On Tue, 14 Sep 2004, Zeev Suraski wrote:
> I don't disagree that it can be useful. But such a feature should not come
> bundled as an option in PHP. The Right(tm) solution here is to provide the
> realpath cache, which will speed performance up without breaking
> compatibility, and hopefully we'
> >It's mostly just looking at the common path and watching the syscalls and
> >getting rid of anything that isn't logically needed to serve up a normal
> >PHP page. I understand that some of these checks are necessary for
> >edge-case things, but when an edge-case check slows down the common case
Zitat von Derick Rethans <[EMAIL PROTECTED]>:
On Tue, 14 Sep 2004, Andi Gutmans wrote:
a) I will try and send internals@ an updated version of the realpath()
cache in the next few days. This should give a lot of bang for the buck
because realpath() is probably the suckiest system call in the startu
On Wed, 15 Sep 2004, Jan Schneider wrote:
> Why not keeping that patch (and others that might be worth it as well) in
> the php-src module, but really as a patch, not applied to the default
> distro? This way it's available at a single point, everyone having a
> tarball can apply it, and it still
Jan Schneider wrote:
> Zitat von Derick Rethans <[EMAIL PROTECTED]>:
>
>> On Tue, 14 Sep 2004, Andi Gutmans wrote:
>>
>>> a) I will try and send internals@ an updated version of the realpath()
>>> cache in the next few days. This should give a lot of bang for the buck
>>> because realpath() is prob
Not sure if this is the right place to ask, but the win32 snapshots on
snaps.php.net don't seem to work anymore. The latest win32 5.X and 5.0.X
builds are 5 days old. And it gives a message like: 'Next Latest CVS Win32
snapshot in: please consult /dev/urandom'.
Thnx.
David
--
PHP Internals - PH
That's because nobody applied the fix after D's patch yet.
> -Original Message-
> From: David Kingma - Jool.nl [mailto:[EMAIL PROTECTED]
> Sent: 15 September 2004 12:03
> To: [EMAIL PROTECTED]
> Subject: [PHP-DEV] Snaps.php.net
>
>
> Not sure if this is the right place to ask, but the win3
Steph wrote:
That's because nobody applied the fix after D's patch yet.
-Original Message-
From: David Kingma - Jool.nl [mailto:[EMAIL PROTECTED]
Sent: 15 September 2004 12:03
To: [EMAIL PROTECTED]
Subject: [PHP-DEV] Snaps.php.net
Not sure if this is the right place to ask, but the win32 s
At 10:03 15/09/2004, Derick Rethans wrote:
On Tue, 14 Sep 2004, Andrey Hristov wrote:
> Both points make sense. Just name the configure option well and put big
warnings there
> that when the option is switched on this _may_ lead to crashing
applications.
Nothing will crash, it's just that includ
On Wed, 15 Sep 2004, Derick Rethans wrote:
> There is also no reason why people would just enable this feature by
> default if they have no clue what they are doing, we can add big
> nice disclaimers around it.
We see idiots submit bug reports with all sorts of configure options
they should never
On Wed, 15 Sep 2004, Adam Maccabee Trachtenberg wrote:
> On Wed, 15 Sep 2004, Derick Rethans wrote:
>
> > There is also no reason why people would just enable this feature by
> > default if they have no clue what they are doing, we can add big
> > nice disclaimers around it.
>
> We see idiots subm
On Wed, 15 Sep 2004, Zeev Suraski wrote:
> Can you share with us what kind of performance increase (vs. the 'much
> inferior' realpath cache or even plain vanilla PHP) we're dealing with
> here? By the way, I can tell you that in real world applications we did
> not manage to measure any performan
At 09:05 AM 9/15/2004 +0200, Derick Rethans wrote:
On Tue, 14 Sep 2004, Andi Gutmans wrote:
> At 10:52 AM 9/14/2004 -0700, Rasmus Lerdorf wrote:
> >The patch doesn't just address realpath though. We have a number of other
> >redundant/non-essential syscalls in the streams code, for example. And
>
At 17:46 15/09/2004, Rasmus Lerdorf wrote:
On Wed, 15 Sep 2004, Zeev Suraski wrote:
> Can you share with us what kind of performance increase (vs. the 'much
> inferior' realpath cache or even plain vanilla PHP) we're dealing with
> here? By the way, I can tell you that in real world applications w
The 161->195 looked a bit high to me so I went back through my notes and
that is actually for the syscall patch plus the non-pic patch. I don't
have numbers for just the syscall patch against stock PHP handy, but I'll
see if I can get some time to run some.
-Rasmus
On Wed, 15 Sep 2004, Rasmus Le
On Wed, 15 Sep 2004, Zeev Suraski wrote:
> That's true, I did kind of forget about the other OS's out there, it's very
> easy to get used to the efficiency of Linux...
> It would be interesting to see how far the realpath cache can get you with
> this app. Can you share that standard benchmark of
Derick Rethans wrote:
On Wed, 15 Sep 2004, Zeev Suraski wrote:
[snip]
I *think* you agree with that, and that we're best off putting it in a
special location, maybe on php.net (if you disagree and I'm putting words
in your mouth, my apologies and I take it back).
Patches are still a hassle to mai
On Wed, 15 Sep 2004, Zeev Suraski wrote:
> That's true, I did kind of forget about the other OS's out there, it's very
> easy to get used to the efficiency of Linux...
> It would be interesting to see how far the realpath cache can get you with
> this app. Can you share that standard benchmark of
Can someone who has more configure knowledge than me volunteer to make our
build system use non-pic for Linux/FreeBSD ia32?
Andi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Rasmus Lerdorf wrote:
> Derick and I are both deploying controlled code on a huge scale and
> turning off edge-case stuff we know we will never use can make a big
> difference. Even a 1 or 2 req/sec difference is significant when you
> serve up billions of pages a day. A good example of that is t
On Mon, 13 Sep 2004 18:50:15 +0300 (IDT)
Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> AD>>It looks like this bug was done intentionally (I'm not sure, just
> AD>an>assumption), so zend_std_get_property_ptr_ptr() doesn't call
> AD>__get.
>
> I'm not sure it should - this would confuse read/writ
On Mon, 13 Sep 2004 14:02:43 +0300 (IDT)
Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> AD>>ATM ZE2 calls destructor at the end of the request and no matter
> AD>is>there were a fatal error (which should probably stop executing
> AD>the>script). In some cases it leads to nasty segfaults (me and
>
Hello Antony,
Maybe this was assumed, but wouldn't this be a per-request flag,
rather than a global flag?
--
Best regards,
Jasonmailto:[EMAIL PROTECTED]
Tuesday, September 14, 2004, 10:18:29 AM, you wrote:
AD> Sounds nice: we should not call destructors after t
At 06:18 PM 9/14/2004 +0400, Antony Dovgal wrote:
Sounds nice: we should not call destructors after they were already called =)
I could propose a simple solution: add a global flag, which will indicate
that shutdown_destructors() was called, and do appropriate check in
zend_objects_store_del_ref().
I am using PHP Version 5.0.1, MySQL 5.0.1-alpha-nt, and Apache/2.0.48 with
Windows XP with SP2. When I use mysql_connect in a php page in Apache to
connect to the "localhost" I get:
Warning: mysql_connect() [function.mysql-connect.chm]: Can't connect to
MySQL server on 'localhost' (10061)
I
On Wed, 15 Sep 2004, Sam Hobbs wrote:
> I am using PHP Version 5.0.1, MySQL 5.0.1-alpha-nt, and Apache/2.0.48 with
> Windows XP with SP2. When I use mysql_connect in a php page in Apache to
> connect to the "localhost" I get:
>
>Warning: mysql_connect() [function.mysql-connect.chm]: Can't conne
On Wed, 15 Sep 2004, Rasmus Lerdorf wrote:
> On Wed, 15 Sep 2004, Sam Hobbs wrote:
> > I am using PHP Version 5.0.1, MySQL 5.0.1-alpha-nt, and Apache/2.0.48 with
> > Windows XP with SP2. When I use mysql_connect in a php page in Apache to
> > connect to the "localhost" I get:
> >
> >Warning: m
At one time, I thought that I read about a problem with PHP4 sessions involving the
recognition of the session expiration in the session engine.
The problem was that the session variables were read into the script's variables
BEFORE the expiration time was checked, or that sesson files were ONLY
On Wed, 15 Sep 2004, Andrey Hristov wrote:
> > Patches are still a hassle to maintain, especially if you're mixing two
> > of them running it on the same code. THey also need updating often due
> > to changes in the distribution. Thinks like that are annoying, although
> > I don't see a better sol
32 matches
Mail list logo