This "fast-and-loose" behavior was what we figured would happen with resources in PHP, especially if you do things in a lower scope that do not get passed back/referenced to a higher scope. Since the concept of scope gets a little gray in PHP we explicitly close the resource in the "scope" it was opened and it still seems that we have the strange "leak", which honestly surprised me. We even explicitly unset the vars but that doesn't guarantee the GC kicks off for them near-time?
As a total aside, and being a paranoid C++ guy, I would love a "free" method that I could call that frees what I tell it to exactly when I tell it to... :-) In any case, we'll apply the steps you outlined to debug the situations and report back what we find. Thanks. - AD -----Original Message----- From: Sara Golemon [mailto:[EMAIL PROTECTED] Sent: Thursday, October 06, 2005 11:58 AM To: "Ron Korving" Cc: internals@lists.php.net Subject: [PHP-DEV] Re: CLI in PHP6 > There was once (can't remember when exactly, so it must be a long time > ago) > here on PHP CLI scripts in which it came forward that one should not rely > on > such a script to run forever. And it's true; the scripts sometimes > magically > and suddenly die. Now I have no clue where this instability (for lack of a > better word) comes from, but could it be possible for this to be resolved > for PHP6 so that PHP becomes an extremely viable solution for CLI daemon > scripts? > The short answer is that PHP plays a little "fast-and-loose" with the data it tracks because it has no idea what you plan on doing with that data. In *theory* allocated resources get cleaned up within a request the minute they no longer have any possible relevance (i.e. A database connection is created within a function, then that function leaves making the variable it was placed in no longer accessible from anywhere). In 99% of the engine/core/exts this happens seemlessly, however there *may* be (and most likely is) a lingering leak somewhere because a file descriptor wasn't closed, or a couple bytes of memory wern't freed. In a "normal" webserver environment these resources get forcibly cleaned up by the end-of-request garbage collection process so they don't get noticed by the bulk of PHP users out there. In a long-running daemon process this GC phase never triggers and those piccune leaks pile up. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php