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: > > >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.
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. >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 -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
