Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51295
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.211.66 cause and error)
To: Antony Dovgal <tony@daylessday.org>
Cc: php-dev <internals@lists.php.net>
In-Reply-To: <4D3548B0.3060601@daylessday.org>
References: <4D305A91.8020806@daylessday.org>
	 <1295288368.3927.26.camel@guybrush>  <4D3548B0.3060601@daylessday.org>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 18 Jan 2011 10:46:23 +0100
Message-ID: <1295343983.2244.3.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] fully enabling dl() for FPM SAPI
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Tue, 2011-01-18 at 11:00 +0300, Antony Dovgal wrote:
> On 01/17/2011 09:19 PM, Johannes Schlüter wrote:
> > I think it can be quite dangerous if you have extensions living shorter
> > than the PHP process. Not only might dlclose() cause some leaks but
> > there are a few extensions playing with function pointers or opcode
> > handlers which aren't properly reset so a following request might try to
> > jump to invalid memory.
> 
> dlclose()? I can assure you I'm not going to call dlclose() on each request shutdown.
> ****
> Yes, that means once an extension is loaded it'll stay till the death of this particular child process).
> But it does work here for the last 5 or 6 years this way and this is indeed what I want.
> ****
> 
> TBH I'm not even sure dlclose() is called at all since I wasn't able to track 
> this call down through all the handlers, destructors and so on in 5 min I spent on this..


module_destructor() calls it and expected it to be hit on rshutdown,
else has really weird behavior - for some processes an extension would
be loaded, for others not which results in non-deterministic behavior
for the outside.

http://lxr.php.net/opengrok/xref/PHP_5_3/Zend/zend_API.c#2120

johannes