-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
never do this:
do { $x = file_get_contents("http://www.example.com/"); } while ($x === false);
or this:
while (!feof($f)) { $x .= fgets($f); }
why not: because if the i/o fails, your script will run forever, using 100% cpu, doing nothing.
instead, add error checking, and exit if there's a problem:
if (($x = file_get_contents("http://www.example.com") === false) { echo "shit happened\n"; exit; }
please make sure none of your scripts have this problem, because they cause issues for all users on the toolserver.
- river.
River Tarnell wrote:
never do this:
[...]
while (!feof($f)) { $x .= fgets($f); }
That may indeed have been a problem with a script of mine; I presumed libc semantics where if the stream had gotten invalid feof() would return an error (and, thus, not 0). At any rate, the script was experimental and has since been disabled, but it's an important gotcha to know of.
-- Marc
why not: because if the i/o fails, your script will run forever, using 100% cpu, doing nothing.
Mh, yeah, I had a similar problem with my scripts. No infinite loop, but a blocking write to a fifo, as my fifo listener process was killed off. I wasted lots of memory with my stale php processes. Sorry about that! I fixed it by adding checks for the fifo listener (using pid files) and aborting the php script if the write would be blocking.
2008/1/23, Daniel Schwen lists@schwen.de:
why not: because if the i/o fails, your script will run forever, using 100% cpu, doing nothing.
Mh, yeah, I had a similar problem with my scripts. No infinite loop, but a blocking write to a fifo, as my fifo listener process was killed off. I wasted lots of memory with my stale php processes. Sorry about that! I fixed it by adding checks for the fifo listener (using pid files) and aborting the php script if the write would be blocking.
Maybe using non-blocking I/O would help too ?:)
AJF/WarX
aborting the php script if the write would be blocking.
Maybe using non-blocking I/O would help too ?:)
That would be the obvious choice. But unfortunately there seems to be no way to realize that in PHP. And furthermore if the fifo has no listener there is no point in writing the data. Having the data queued until the listener comes up again would just create a huge backlog of work (map tiles to be rendered) which no one would care about (since the requests for those tiles timed out anyways).
On Jan 23, 2008 6:22 PM, Daniel Schwen lists@schwen.de wrote:
aborting the php script if the write would be blocking.
Maybe using non-blocking I/O would help too ?:)
That would be the obvious choice. But unfortunately there seems to be no way to realize that in PHP. And furthermore if the fifo has no listener there is no point in writing the data. Having the data queued until the listener comes up again would just create a huge backlog of work (map tiles to be rendered) which no one would care about (since the requests for those tiles timed out anyways). -- [[en:User:Dschwen]] [[de:Benutzer:Dschwen]] [[commons:User:Dschwen]]
Toolserver-l mailing list Toolserver-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/toolserver-l
http://nl2.php.net/manual/fi/function.stream-select.php ?
Bryan
That would be the obvious choice. But unfortunately there seems to be no way to realize that in PHP. And furthermore if the fifo has no listener
How do I get a stream object to pass to stream_select? fopen? fopen is already blocking if my fifo listener is dead.
On Jan 23, 2008 6:53 PM, Daniel Schwen lists@schwen.de wrote:
That would be the obvious choice. But unfortunately there seems to be no way to realize that in PHP. And furthermore if the fifo has no listener
How do I get a stream object to pass to stream_select? fopen? fopen is already blocking if my fifo listener is dead. --
[[en:User:Dschwen]] [[de:Benutzer:Dschwen]] [[commons:User:Dschwen]]
Toolserver-l mailing list Toolserver-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/toolserver-l
Ah I assumed that the blocking occurred in fread. stream_select won't work for fopen :(
Bryan
Btw, there's a *very* beta (and not currently maintained) event extension on pecl somewhere that supports epoll(), kqueue(), etc. I haven't played too much with it, because in cases where I need to use advanced polling engines I probably don't need to be using PHP for whatever I need to do :P
Anyway, the easiest solution whenever you need to do something involving a while() is almost *always* have a sleep() or usleep() call at the end of it. Even if it's only a miniscule stop it tends to make a big difference depending on what you're doing. Another failsafe is turning a while() into a for() loop with an arbitrary upper bounds (100000 for example) during debugging. At least that way, when you're testing things out, if something gets out of hand, the loop will break on its own. From that point, it's easy to simply convert the for() back to a while() once you know nothing bad will happen.
Cheers. -slakr (@en.wp)
On Wednesday 23 January 2008 11:56, Bryan Tong Minh wrote:
On Jan 23, 2008 6:53 PM, Daniel Schwen lists@schwen.de wrote:
That would be the obvious choice. But unfortunately there seems to be no way to realize that in PHP. And furthermore if the fifo has no listener
How do I get a stream object to pass to stream_select? fopen? fopen is already blocking if my fifo listener is dead. --
[[en:User:Dschwen]] [[de:Benutzer:Dschwen]] [[commons:User:Dschwen]]
Toolserver-l mailing list Toolserver-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/toolserver-l
Ah I assumed that the blocking occurred in fread. stream_select won't work for fopen :(
Bryan
Toolserver-l mailing list Toolserver-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/toolserver-l
toolserver-l@lists.wikimedia.org