Shane, Please read the archives - the performance issue was well covered.
The stability issue is fairly obvious (you're much more likely to screw up in a multithreaded environment if you load/unload libraries like hell, than you are if you load them once, process-wide; this affects both code in PHP and code in the libraries themselves). The security issue is fairly obvious as well - by definition, if you let users load arbitrary code in runtime, from within a script, you're begging for trouble. Of course, if PHP was a fort it wouldn't have been a problem but you know it is not. There's nothing theoretical about these drawbacks, they're very concrete. On the other hand, I can only find theoretical advantages to using dl() (or for that matter, not using php.ini); You said you don't like it, but there's really nothing wrong with it). Zeev At 01:00 12/03/2002, Shane Caraveo wrote: > > >The issue to me is a matter of usability. I want to have a single > > >installation of PHP, but may have many different situations under which I > > >use that installation. Perhaps one application uses modules x, y and z > > >extensively, another uses a, b and c extensively, and perhaps d very >rarely. > > >Lets say neither uses extensions the other app uses. The current >situation > > >is that I must load all extensions in php.ini irregardless of use, or I >must > > >use -c to specify an ini file, etc. I prefer not to load extensions >unless > > >I really need them, but PHP simply does not provide an easy effective >means > > >to do that. Perl and Python both do and you never have to think about > > >messing with an ini file. I think far PHP has put far too much reliance >on > > >the ini file. > > > > I don't know many production installations where all extensions wouldn't >be > > dl()'ed within a few seconds even if there are what you call *rarely* used > > scripts. I think your examples are theoretical and the ini change can be > > done quite easily even by a dumb automatic installation script. > >Only as theoretical as the arguments against dl appear to me, and it doesn't >matter if all dl()'d libraries are loaded right away, it matters that dl is >extremely more flexible than dealing with php.ini. It's funny, I recall >being the one to want php.ini for php3. Now I find it the single most >frustrating thing about php. > > > In any case, I still think a solution can be found I just don't have any > > concrete ideas on how to fix it. > >Thus why I wanted to reopen this discussion. I think a solution can be >found, and I don't feel it's right to shut out the issue because a >'solution' exists in the ini file, or because of unexplained claims of >performance, stability and security issues. Without real thought on it, and >a real explaination of the issues, no solution will be found. The only >valid explaination I found was that the module init ends up getting called >twice, resulting in a performance issue. There was something else about >garbage collection of classes. That kind of information is the kind that is >important to know. Concrete issues are fixable. > >Of course loading libraries at run time are going to be slower performing >and non-optimizable in certain situations. Dynamicaly loading anything is, >and we dynamicly load everything. I cannot imagin any real concrete reasons >against dl. Any previous archive email about dl I read failed to convince me >that dl should be deprecated. > > > By the way, you mentioned perl as an example. I have no idea how perl >works > > in multi-threaded environments but if you say it works very nicely with > > perl & multi-threaded servers then I take your word for it. > >I have worked on a multi-threaded perl server at work (PerlEx). There is no >issue with dynamic loading of modules unless, of course, they are not thread >safe. Dynamic loaded modules remain loaded until the interpreter is shut >down, so there is no performance issue except on the first load. Commonly >loaded modules can be preloaded to avoid the initial hit during script >execution. > >Shane > > > > > > >-- >PHP Development Mailing List <http://www.php.net/> >To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
