Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
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 solution for this now (except by doing it the > > kernel way and use --enable-expirental-foo for example). > > > Or just don't expose --enable-experimental-foo option but make it possible > by changing a simple #define somewehere. As it is possible to move with > one change from Zend's MM to libc malloc() and company. Works too for me. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] session workings, please
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 deleted by the garbage collection routine. Anyone remember this? So, I'm asking if someone here can answer to which order the following tasks run when a script is requested? [A] read session file if file and PHPSESSID both exist at request time [B] delete sesssion if expired (is there a separate process for this, or does only garbage collection delete sessions?) [C] load session vars [D] run garbage collection -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysql_connect using version 5.0.1 accesses the internet when host and client are the same system
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: mysql_connect() [function.mysql-connect.chm]: Can't connect to > > MySQL server on 'localhost' (10061) Also, are you really using the mysql extension with MySQL 5.0.1? If so, you need to make sure you pass special flags to MySQL to make it play nice with the older client libraries. -adam -- [EMAIL PROTECTED] author of o'reilly's "upgrading to php 5" and "php cookbook" avoid the holiday rush, buy your copies today! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysql_connect using version 5.0.1 accesses the internet when host and client are the same system
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 connect to > MySQL server on 'localhost' (10061) > > I get that when the firewall does not allow Apache and MySQL to access the > internet. When I do allow Apache to access the internet, mysql_connect with > the same parameters works. Is that waht is supposed to happen? > > I assume this is a PHP problem but I can't be sure it is, so I apologize if > it is not. I am not sure why you assume this to be a PHP problem. Sounds like your firewall is blocking both local and external connections. Can you telnet to port 10061 on localhost with the firewall enabled? -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] mysql_connect using version 5.0.1 accesses the internet when host and client are the same system
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 get that when the firewall does not allow Apache and MySQL to access the internet. When I do allow Apache to access the internet, mysql_connect with the same parameters works. Is that waht is supposed to happen? I assume this is a PHP problem but I can't be sure it is, so I apologize if it is not. I realize that I have not provided much information. If access to the internet is normal when the server and client are in the same system, then I won't spend much more time on this. If however it sounds like a bug, then I will gather as much information that I can and submit a bug report. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] Zend/zend_objects_API.c - bug #29980 (segfault while executing __destruct())
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(). Comments/objections? I prefer not to add another if() to this method. I did my best to keep it as slim as possible. We could run over the object store and mark all destructors as already called. That might be the best solution and wouldn't slow down the general case of objects being destroyed during script execution, but if there are lots of global objects it would potentially slow down the shutdown. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] Zend/zend_objects_API.c - bug #29980 (segfault while executing __destruct())
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 they were already called =) AD> I could propose a simple solution: add a global flag, which will indicate AD> that shutdown_destructors() was called, and do appropriate check in AD> zend_objects_store_del_ref(). AD> Comments/objections? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] Zend/zend_objects_API.c - bug #29980 (segfault while executing __destruct())
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 > AD>report's>author can reproduce it, but others can't. weird..). > > Well, the cause of the faults is as follows: > If we are in shutdown, and one of the destructors fails with fatal > error, then other destructors for other objects are not called. Thus, > their if they hold some objects, destructors for these objects will > not be called. Later, when the storage is cleaned with > zend_objects_store_free_object_storage(), engine will attempt to call > dtors for objects that didn't have their dtors called before. However, > on that stage engine is already unable to run PHP code (function and > class tables are already cleaned, etc.) - so it crashes. Looks like you're right, but why others can't reproduce this segfault? > What I would propose is to inhibit calling destructors after > shutdown_destructors() was finished. 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(). Comments/objections? -- Wbr, Antony Dovgal aka tony2001 [EMAIL PROTECTED] || [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] Zend/zend_object_handlers.c - bug #29378 (foreach() doesn't work with arrays returned by __get)
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/write operators like > object increments. Hmm.. could you provide any examples? I just want to test them with the patch and see maybe I can adopt it. >I think it should be talen care of elsewhere. Any ideas where? -- Wbr, Antony Dovgal aka tony2001 [EMAIL PROTECTED] || [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
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 the pipe > checks. I really don't need the ability to pipe scripts to be parsed by > PHP and I am not willing to take the 2-syscall hit on every one of my > requests to support this. Or the non-pic patch which we can't really > deploy on a large scale because libtool is too stupid, but this patch > provides an instant 10-20% performance increase on both ia32 FreeBSD and > Linux while breaking ia64 Linux and AIX I think. Is there actually any url/listing of those other patches? After applying the non-PIC patch myself and seeing performance improvements with my php apps I'm really looking forward for more patches like this (they only break edge-case stuff and performance improvement is noticeable). -- Juan Alonso http://gamersmafia.com | http://laflecha.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
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
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
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 yours? http://lerdorf.com/bench.tar It's actually a really crappy benchmark. When you profile it you see that it spends most of its time in var_dump(). I have been working on a better one that touches more of PHP evenly. > 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). I am not sure what the right solution is. I would like to see this patch and others like it be more visible in a way that when someone changes something that either affects the patch or perhaps even incorporates part of it, the patch is updated. I have a number of these sitting around that could be very useful but are somewhat limited in terms of their audience. We need some sort of better balance between safe vanilla code that runs everywhere for everyone and platform-specific or audience-specific stuff. 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 the pipe checks. I really don't need the ability to pipe scripts to be parsed by PHP and I am not willing to take the 2-syscall hit on every one of my requests to support this. Or the non-pic patch which we can't really deploy on a large scale because libtool is too stupid, but this patch provides an instant 10-20% performance increase on both ia32 FreeBSD and Linux while breaking ia64 Linux and AIX I think. Having the patches in the code itself could lead to an #if mess, especially since they may conflict. But on the other hand having them there would get people thinking about whether some of these things could be worked around or done in a better way and code changes would automatically be reflected in them. Perhaps a decent patch repository is the way to go. One that would keep track of patches by PHP version number and branches and periodically test-apply the patches against the trees and notify the patch maintainers of breakage. I don't really care about this particular patch, and I am nowhere near as keen as Derick on seeing a configure switch for it, what I would like to see is a system for dealing with these patches that would encourage more of them which in turn would lead to a lot of new ideas flowing into the project. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
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 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 solution for this now (except by doing it the kernel way and use --enable-expirental-foo for example). Or just don't expose --enable-experimental-foo option but make it possible by changing a simple #define somewehere. As it is possible to move with one change from Zend's MM to libc malloc() and company. Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
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 yours? We have "instructed" a customer to test it (running freebsd) and he'll benchmark it, and also watch diskio and sustem load. When they report back I'll share it of course. > Yes, I would know that. But it breaks when it's most needed. In my > experience the circumstances where it won't work properly are extremely common. But for those people this patch isn't interesting anyway. It's only interesting if you have a dedicated server running. People can easily test their applications for this too. > 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 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 solution for this now (except by doing it the kernel way and use --enable-expirental-foo for example). Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
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 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 we did > > not manage to measure any performance gain from the realpath cache, even > > though we measured 35% performance improvement in a synthetic test, and I > > expect it to be quite similar with this patch. Before we introduce such a > > big potential for breakage at the fingertips of every user, let's be sure > > it's worth it. > > It depends completely on your operating system. Benchmark an application > on FreeBSD 4.x that has a lot of includes and you can't miss it. My > standard benchmark, which doesn't actually do very many file ops went from > 161 requests/second to 195 requests/second with this patch. > > On operating systems like Linux where syscalls are much lighter, you won't > see anywhere near that. But you are still going to see a difference. If > you couldn't measure a performance gain then it was lost in some serious > other noise in your test. You will typically go from something like 120 > stats, seeks and ftells down to 8 or 9 per request with the patch. > > And by the way, include_once doesn't completely break. It will still > catch multiple includes of the same path which is usually what people are > interested in. It just won't catch something like: > > include_once 'file.inc'; > include_once '../dir/file.inc'; > > assuming file.inc is in 'dir'. And while that is significant, in > deployments where you have full control over the code or the ability to > just whack people and tell them not to do stupid stuff like that, it > becomes a non-issue. > > -Rasmus > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
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 we did > not manage to measure any performance gain from the realpath cache, even > though we measured 35% performance improvement in a synthetic test, and I > expect it to be quite similar with this patch. Before we introduce such a > big potential for breakage at the fingertips of every user, let's be sure > it's worth it. It depends completely on your operating system. Benchmark an application on FreeBSD 4.x that has a lot of includes and you can't miss it. My standard benchmark, which doesn't actually do very many file ops went from 161 requests/second to 195 requests/second with this patch. 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 yours? On operating systems like Linux where syscalls are much lighter, you won't see anywhere near that. But you are still going to see a difference. If you couldn't measure a performance gain then it was lost in some serious other noise in your test. You will typically go from something like 120 stats, seeks and ftells down to 8 or 9 per request with the patch. True, but the bottom line is that it wasn't noticeable in real world apps. It was lost in the noise, except the noise happened to be the application code itself (several apps we took as-is from the web). In a synthetic benchmark designed to measure just the performance of include()'s we measured a significant performance gain (~30%). And by the way, include_once doesn't completely break. [snip] Yes, I would know that. But it breaks when it's most needed. In my experience the circumstances where it won't work properly are extremely common. assuming file.inc is in 'dir'. And while that is significant, in deployments where you have full control over the code or the ability to just whack people and tell them not to do stupid stuff like that, it becomes a non-issue. I don't see why you think this is 'stupid' (of course, when it's not done within the same file). Again, it's extremely common and actually the whole point behind include_once() . I do agree that if you have centralized control over your code you can force people not to use it, but that can apply to just about any other feature in PHP. We can probably have some --disable-indirect-reference switch that might enable us to get an extra bit of performance, do we want to get into this business? I think not. Where do we draw the line? The only way to draw it is to make it stupid-simple - if it allows users to selectively break (or alter) language functionality, it shouldn't be in the standard distribution. We have some old leftovers that don't follow these guidelines, but at least most of them are changeable in runtime (allowing for portable code), and all of them are at the very least can be configured in php.ini. 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). Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
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 > >the realpath cache is still heavier than not worrying about the full path > >at all. > > Can you describe the other non-essential syscalls? I want to be sure we > really can't cover those (probably some of them we can't). > As far as the realpath patch goes (which is probably the biggest problem), > I think that if we have the realpath cache in CVS that part of your patch Will you backport that realpath cache to PHP 4.3? I don't see a reason why not to backport this patch to 4.3. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
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 performance gain from the realpath cache, even > though we measured 35% performance improvement in a synthetic test, and I > expect it to be quite similar with this patch. Before we introduce such a > big potential for breakage at the fingertips of every user, let's be sure > it's worth it. It depends completely on your operating system. Benchmark an application on FreeBSD 4.x that has a lot of includes and you can't miss it. My standard benchmark, which doesn't actually do very many file ops went from 161 requests/second to 195 requests/second with this patch. On operating systems like Linux where syscalls are much lighter, you won't see anywhere near that. But you are still going to see a difference. If you couldn't measure a performance gain then it was lost in some serious other noise in your test. You will typically go from something like 120 stats, seeks and ftells down to 8 or 9 per request with the patch. And by the way, include_once doesn't completely break. It will still catch multiple includes of the same path which is usually what people are interested in. It just won't catch something like: include_once 'file.inc'; include_once '../dir/file.inc'; assuming file.inc is in 'dir'. And while that is significant, in deployments where you have full control over the code or the ability to just whack people and tell them not to do stupid stuff like that, it becomes a non-issue. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
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 submit bug reports with all sorts of configure options > they should never use, like --enable-experimental-zts, which is > described in configure as "This will most likely break your build". That's why we have quickfixes in our bug system. ALthough I can not remember somebody who used this setting and filed a bug because of it. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
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 use, like --enable-experimental-zts, which is described in configure as "This will most likely break your build". -adam -- [EMAIL PROTECTED] author of o'reilly's "upgrading to php 5" and "php cookbook" avoid the holiday rush, buy your copies today! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
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 include_once might fail if you're
using two different paths to include it.
I apologize if I didn't make it clear that I did not refer to C level
crashes (segfaults) but rather application crashes ('function X
redeclared', etc., or apps breaking in a variety of interesting ways -
that's a crash all the same).
include_once() breaking is a insanely high price to pay that mustn't be
taken lightly. It won't be the only thing, anything that relies on
opened_path being accurate will not work properly, include_once() is one
example, code that uses __FILE__ and php.ini's location in phpinfo() are
two others I can think of off hand. There was life before opened_path, and
it wasn't pretty - we introduced it for a reason - it was needed in all
sorts of places.
No big deal and easy to fix too
IF you need this kind of performance increase. Big warnings is fine with
me :)
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 performance gain from the realpath cache, even
though we measured 35% performance improvement in a synthetic test, and I
expect it to be quite similar with this patch. Before we introduce such a
big potential for breakage at the fingertips of every user, let's be sure
it's worth it.
Again, my view is that it's exactly in the opposite direction of where
we've been pushing PHP in the last few years, striving for maximum
compatibility even when it comes at a cost. Unless the cost is unbearable
(waiting for the numbers) I see no reason to deviate from these guidelines,
even if a few people find it interesting. It's the millions who don't that
we should think about.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Snaps.php.net
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 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 Derick just patched the windows build so probably there will be binaries soon. Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Snaps.php.net
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 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 - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Snaps.php.net
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 - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
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 probably the suckiest system call in the startup. >>> b) Maybe Wez & Sara can take one more look to double check if there aren't >>> any checks they can possibly save without impairing functionality. >>> c) Create a new version of your patch based on (a) & (b) and make sure we >>> find an accessible place for it with the disclaimer. >> >> >> >> A good accessible place would be our distribution. It's annoying to have >> to maintain a patch outside the main tree. 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. I can >> see nothing wrong with it, I also don't think this is a nasty hack or a >> crappy patch. I do not seek to have this patch into PHP 5, you can do >> your realcache magic there if you want. > > > > 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 won't be available with a simple config > option. > > Jan. > > -- > Do you need professional PHP or Horde consulting? > http://horde.org/consulting/ > If kept like this it has to be updated, which almost no different from the case being on zend.com . To make it harder for someone to shoot himself then let it in without configure option but a #define somewhere. If someone wants to compile it with this support (s)he has to change the value of the #define. Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
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 won't be available with a simple config > option. Because it won't solve the main thing: maintenance. And patching is not something that a lot of people are familiar with, it's also a hassle to do. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
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 startup. b) Maybe Wez & Sara can take one more look to double check if there aren't any checks they can possibly save without impairing functionality. c) Create a new version of your patch based on (a) & (b) and make sure we find an accessible place for it with the disclaimer. A good accessible place would be our distribution. It's annoying to have to maintain a patch outside the main tree. 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. I can see nothing wrong with it, I also don't think this is a nasty hack or a crappy patch. I do not seek to have this patch into PHP 5, you can do your realcache magic there if you want. 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 won't be available with a simple config option. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
> >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 I > >sacrifize that edge. > > Yep it seems like some of these are things which a realpath() cache patch > would not address. As I mentioned earlier we should make your patch > available but I think it's a bad idea to have it in the default distro. > I suggest the following: > 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 more look to double check if there aren't > any checks they can possibly save without impairing functionality. > c) Create a new version of your patch based on (a) & (b) and make sure we > find an accessible place for it with the disclaimer. Maybe Steph can take > care of that. As I'm very interested in this patch and patches like this I send this reply to make a suggestion. 1) This patch can and will break some applications, the users needs to be aware of this. So a big warning needs to be shown to the user. 2) Application vendors should be able to advice their customers to tune PHP to run an application and the vendor will then say which patch you can safely run or not. So the patch should be available easily. 3) Having patches available means that they can be improved by many people and Rasmus doesn't need to maintain this, which means less work load on him. 4) Making the realpath() cache is a good thing, but it is not the same. So like winnie the pooh I would say yes, both please. 5) If we create a patch repository somewhere this would make the patches available, but it will be much more hazzle for the users - which is not good. If a user wants to use several patches from this repository he needs to download the patches verify that he has the correct version and also verify that one patch does not break another. The latter point can quickly be an issue since if you have a patch repository then it could be a pain to make sure that all patches are compatible with eachother. What about doing it similar to the way the Linux kernel does this. We could add --experimental compile options. E.g. --experimental- (or --non-standard- or another good indicating name for that matter ). So adding --exeprimental-minimize-statcall could enable this patch. After the build is done there should be a big fat warning about the different experimental patches with links to information about them. E.g. detailed information about what they will break. In phpinfo() it should also be a list with experimental options, mabye even in bold/red font to make it very clear. Atleast I find it simpler to advice e.g. a hosting company to enable --experimental--foo to boost performance rather than tell them to download, make sure you have the correct version and patch. And in the end it's the end users we would like to make things simpler for right? Atleast this is what I think about the matter. We would gladly spend the time eneded to make what I describe above. Cheers, -- Bård Farstad [EMAIL PROTECTED] | eZ systems | http://ez.no -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
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'll have that one real soon now. We can > maybe look into backporting it to PHP 4 as an optional feature (just to > make sure we don't break apps in case it's buggy). The realpath cache is not nearly what Rasmus patch does. Besides that, the patch seems to be rock solid (we've customers running it in production now). > Adding this patch as an option goes against everything that we've been > trying to do in the last few years. This useful patch should be made > available so that those who really need it can find it, but it should come > up with a huge disclaimer, and it should not be trivial for users to enable > it in the form of --enable-foo. I see the fact that people have to invest > some work in using it as a good thing, since if a lot of people start using > it, it can become a very big headache very quickly. --enable-foo=40digit-prime-of-your-choice? For people who use it, they would use this professionally. They are most often not even *allowed* to patch their PHP nor do they want to spend time on applying this patch each time. Also, it's not an inherently bad patch either. You just need to make sure that 1) you don't use symlinks and 2) always include a file with the same file path. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
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 more look to double check if there aren't > any checks they can possibly save without impairing functionality. > c) Create a new version of your patch based on (a) & (b) and make sure we > find an accessible place for it with the disclaimer. A good accessible place would be our distribution. It's annoying to have to maintain a patch outside the main tree. 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. I can see nothing wrong with it, I also don't think this is a nasty hack or a crappy patch. I do not seek to have this patch into PHP 5, you can do your realcache magic there if you want. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
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 worrying about the full path > >at all. > > Can you describe the other non-essential syscalls? I want to be sure we > really can't cover those (probably some of them we can't). > As far as the realpath patch goes (which is probably the biggest problem), > I think that if we have the realpath cache in CVS that part of your patch Will you backport that realpath cache to PHP 4.3? Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
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 different paths to include it. No big deal and easy to fix too IF you need this kind of performance increase. Big warnings is fine with me :) Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
