Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51292
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain daylessday.org designates 89.208.40.236 as permitted sender)
Message-ID: <4D3548B0.3060601@daylessday.org>
Date: Tue, 18 Jan 2011 11:00:48 +0300
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20101125 SUSE/3.0.11 Thunderbird/3.0.11
MIME-Version: 1.0
To: =?UTF-8?B?Sm9oYW5uZXMgU2NobMO8dGVy?= <johannes@schlueters.de>
CC: php-dev <internals@lists.php.net>
References: <4D305A91.8020806@daylessday.org> <1295288368.3927.26.camel@guybrush>
In-Reply-To: <1295288368.3927.26.camel@guybrush>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] fully enabling dl() for FPM SAPI
From: tony@daylessday.org (Antony Dovgal)

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..

> Additionally there's no restriction on this once safe_mode is gone, so
> anybody could load any C extension - while that can be fixed by
> advertising disable_function=dl

That's right, disabling it is not a problem.

-- 
Wbr,
Antony Dovgal
---
http://pinba.org - realtime statistics for PHP