> >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
