Re: dl() equivalent
| From: | Andi Gutmans | Date: | Sun, 28 Oct 2001 05:52:55 +0000 |
| Subject: | Re: dl() equivalent | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-69164@lists.php.net to get a copy of this message | ||
At 01:40 AM 10/28/2001 +0200, Stig S. Bakken wrote:
Andi Gutmans wrote: At 08:43 AM 10/27/2001 +0200, Stig S. Bakken wrote:Why do we have to provide such a solution? I complete disagree that having extensions sit outside the tree makes any difference? Today you'd compile them in statically, tomorrow you can add them via php.ini.Hi, Back in the early 3.0 days, dl() used to load stuff into the process without removing it at the end of the request. Zeev, would not yanking modules back out at request shutdown eliminate some of the evilness of dl()?That is probably a possibility. But why not have the person add it to php.ini and not deal with any evilness? :) I think your proposal is probably a good solution for BC but I'd try to officially deprecate the function. The way I see it, we must provide some way to load an extension without having access to php.ini. If we don't have that, we can't move extensions out of the PHP distribution, and if we can't move extensions out, our release cycle will become even more painful, and I fear the quality of PHP will suffer. It's a pretty bad catch 22, but there's no escaping it.
Zeev/Andi, if you have the energy to list the problems involved in providing a runtime loading function (that doesn't have to clean up), maybe php-dev can help finding solutions?I think in general it is memory which is leaked in debug mode will crash. However, there might be other situations where the extensions registers stuff or callbacks during its lifetime which will make PHP crash later on. I don't know all of the situations. Andi