On Sun, 17 Aug 2003, Steve Langasek wrote: > http://bugs.debian.org/131080 > http://bugs.debian.org/131724 > http://bugs.debian.org/165699 > http://bugs.debian.org/165718 > http://bugs.debian.org/165719 > http://bugs.debian.org/166414 > http://bugs.debian.org/188014 > http://bugs.debian.org/188025 > http://bugs.debian.org/188058 > http://bugs.debian.org/189202 > http://bugs.debian.org/189653 > http://bugs.debian.org/200255 > http://bugs.debian.org/205592
Most of these seem to be symbol clash problems (Ok, I didn't read them all) or problems vaguely attributed to Apache's double init phase on startup. Your conclusion that pushing towards dl() instead of figuring out what is messing up the extension=foo.so style of loading libraries is misguided. dl() is slow because the library is loaded and unloaded on every single request. dl() is clunky because it isn't, and I don't see how it could ever be, threadsafe. And finally it has some nasty security implications. I understand you want to address these with safemode changes, but many servers don't run safemode (because it is not actually very safe and in general it is crap) and the damage a user can do is somewhat limited. By forcing them to allow dl() users can now load arbitrary C code directly into the web server process and really really mess stuff up. Nobody here is saying that we don't want to support folks building binary distributions of PHP. We are just saying that your chosen path is a bad idea and that we need to address the real problem instead. Architecturally it makes absolutely no sense to load and unload libraries on a per-request basis. This has to happen at server startup. One thing we should probably do is not dlclose() any shared extensions on shutdown. I am not sure if your list of bugs included any reports of crashes on shutdown, but if you ever come across one of those it is likely that removing the dlclose() will fix it. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
