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:pollita@php.net]
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.
