<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Olly Betts wrote:
<blockquote cite="mid20060420151700.GF20016@survex.com" type="cite">
<pre wrap="">On Thu, Apr 20, 2006 at 05:11:14PM +0200, Daniel M?nard wrote:
</pre>
<blockquote type="cite">
<pre wrap="">BTW, you remember me a problem I had with my wrapper and that I have not
investigated : I had to explicitely release the object (php should do it
automatically). For example, with a WritableDatabase, the lock file was not
removed if I didn't write "$db=null".
</pre>
</blockquote>
<pre wrap=""><!---->
For the wrapper class, or for the resource thing that you pass to the
flat API?
I believe SWIG sets a destructor to run on the resource, but I guess PHP
doesn't call it (I notice simpleindex.php explicitly sets the database
to Null).
</pre>
<blockquote type="cite">
<pre wrap="">I will have to test the new wrapper to check that we don't have a similar
problem.
</pre>
</blockquote>
<pre wrap=""><!---->
If it doesn't, we can easily generate a destructor to explicitly set the
swig_ptr to Null. Assuming PHP always runs object destructors which
I'd really hope it does...
</pre>
</blockquote>
Aye this is a sticky area. php till php5 actually hasn't had any proper
object destructors.<br>
<br>
PHP carefully tracks memory allocations to free them, and it ref-counts
and we get our destructor called then (which is why setting to null
works), but it looks like on page shutdown time the memory is free'd
but the destructors are not called. Shame on php. <br>
<br>
This of course means that there will be memory leaks too (under apache)<br>
<br>
Looks like swig-php needs a hash or collection of allocated objects so
it can free them on php shutdown;<br>
I don't now if this is true now but it will be when swig handles
callbacks a bit better, wrapped objects might have references to php
objects which have references to wrapped objects.... indeed.<br>
<br>
PHP - before proper php destructors - has had
register_shutdown_function (or something with a similar name) where
code could be specified to clean up resources on php shutdown.<br>
<br>
We should perhaps look and see how mysql handles closing non persistent
connections on shutdown and get tips from there, but could at least
perhaps do some register_shutdown_function when wrapped objects are
returned, perhaps by keeping a private hash of object references and
iterating over those afterwards.<br>
<br>
Private php hashes are done with static vars:<br>
<br>
class whatever {<br>
function &private_hash() {<br>
static $hash;<br>
if (! isset($hash)) $hash=array();<br>
return $hash;<br>
}<br>
}<br>
<br>
$hash=&whatever::private_hash();<br>
<br>
that type of stuff - but it would keep an extra ref, of course, so
$db=NULL would not work....<br>
<br>
it's hell!<br>
<br>
I recall that MSIE has memory leaks related to javascript objects
referencing dom stuff which itself references javascript stuff.<br>
<br>
Sam<br>
</body>
</html>