Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Fwd: Re: dl() problem »

Fwd: Re: dl() problem

php.internals

Andi Gutmans

22 years ago

Andi Gutmans

22 years ago
Pierre, Just to add to this, the fact that it's deprecated doesn't mean you can't use it. It just means that there are known bugs which won't be fixed and the function won't be maintained. We've been through this a few times in the past few years and the conclusion has always been that dl() sucks. Andi At 02:05 PM 2/11/2004 +0200, Andi Gutmans wrote:

Derick Rethans

22 years ago
On Wed, 11 Feb 2004, Andi Gutmans wrote:
> Pierre, > > Just to add to this, the fact that it's deprecated doesn't mean you can't > use it. > It just means that there are known bugs which won't be fixed and the > function won't be maintained. > We've been through this a few times in the past few years and the > conclusion has always been that dl() sucks.
Besides that, this should work fine too: php -dextension=php_gtk.so -dextension=foo.so script.php if this doesn't work, I think that should be fixed :) Derick

Pierre-Alain Joye

22 years ago
Organization: Freelancer X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 11 Feb 2004 14:07:16 +0200 Andi Gutmans <andi@zend.com> wrote:
> Pierre, > > Just to add to this, the fact that it's deprecated doesn't mean you > can't use it. > It just means that there are known bugs which won't be fixed and the > function won't be maintained. > We've been through this a few times in the past few years and the > conclusion has always been that dl() sucks.
Well, php dl sucks? Why it sux for php and not for other langages? (not kidding here :) ). I feel this problem in the same way as the auto* tools. Each time someone came in and say: "got errors using version x", "we" answer please use the(damn old) version 2.x or whatever. As most of other applications use recent auto* tools without problem. If we have to deprecate dl, then we have to provide an alternative (aka python import for instance). pierre

Stanislav Malyshev

22 years ago
PJ>> Well, php dl sucks? Why it sux for php and not for other langages? PJ>> (not kidding here :) ). Which languages are you talking about? The general answer is, obviously, "PHP is not <insert your favorite language here>", but let's go specific - what language and what do you mean by that? PJ>> If we have to deprecate dl, then we have to provide an alternative PJ>> (aka python import for instance). What alternative do you propose? What should it achieve that extension= doesn't?
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.109

Derick Rethans

22 years ago
On Wed, 11 Feb 2004, Stanislav Malyshev wrote:
> PJ>> Well, php dl sucks? Why it sux for php and not for other langages? > PJ>> (not kidding here :) ). > > Which languages are you talking about? The general answer is, obviously, > "PHP is not <insert your favorite language here>", but let's go specific - > what language and what do you mean by that? > > PJ>> If we have to deprecate dl, then we have to provide an alternative > PJ>> (aka python import for instance). > > What alternative do you propose? What should it achieve that extension= > doesn't?
1. dl() is nice in CGIs where you don't want to load all extensions for each request as that is slow (but CGI is slow anyway :) 2. for PHP GTK you usually don't want the extension=php_gtk.so line as it inteferes with normal operation. I think that both points are not really relevant enough though to put in any effort to fix dl() because you can still use it. (And dl() in those cases is just fine too, as it's just one request per process and is very unlikely to fuck up things). Any idea why php -dextension=php_gtk.so doesn't work btw? regards, Derick

Andrei Zmievski

22 years ago
On Wed, 11 Feb 2004, Derick Rethans wrote:
> 2. for PHP GTK you usually don't want the extension=php_gtk.so line as > it inteferes with normal operation.
How does it interfere with normal operation? - Andrei

Pierre-Alain Joye

22 years ago
Organization: Freelancer X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 11 Feb 2004 14:41:19 +0200 (IST) Stanislav Malyshev <stas@zend.com> wrote:
> Which languages are you talking about? The general answer is, > obviously, "PHP is not <insert your favorite language here>", but > let's go specific - what language and what do you mean by that?
python in my case. And not only langages, please check any tools that allows dynamic load of extensions.
> What alternative do you propose?
A python "import" like. Drop/deprecate dl and implement a nice thing from scratch ( :-D ). Not really possible regarding the current deadlines.
> What should it achieve that extension= doesn't?
- "extension=" is not always possible (no access to php.ini). It's a fact. - CLI/CGI (as pointed by Derick, but being wrong while saying (fast)cgi is slow ;) ) application which loads extensions if required. gtk is one example, but can we drop all the unknown userland application? - Is it possible to load an extension only in one part of a host? (RTFM?) Does "Deprecated" mean that the function may be droped in any future major release? If yes, the cgi/cli @dl() will not work anymore, and it's not that good. pierre

Derick Rethans

22 years ago
On Wed, 11 Feb 2004, Pierre-Alain Joye wrote:
> - CLI/CGI (as pointed by Derick, but being wrong while saying (fast)cgi > is slow ;) )
No, CGI is slow and for FastCGI dl() is a problem again. Derick

Sascha Schumann

22 years ago
On Wed, 11 Feb 2004, Derick Rethans wrote:
> On Wed, 11 Feb 2004, Pierre-Alain Joye wrote: > > > - CLI/CGI (as pointed by Derick, but being wrong while saying (fast)cgi > > is slow ;) ) > > No, CGI is slow and for FastCGI dl() is a problem again.
Why would dl() be a problem for FastCGI? - Sascha

Derick Rethans

22 years ago
On Wed, 11 Feb 2004, Sascha Schumann wrote:
> On Wed, 11 Feb 2004, Derick Rethans wrote: > > > On Wed, 11 Feb 2004, Pierre-Alain Joye wrote: > > > > > - CLI/CGI (as pointed by Derick, but being wrong while saying (fast)cgi > > > is slow ;) ) > > > > No, CGI is slow and for FastCGI dl() is a problem again. > > Why would dl() be a problem for FastCGI?
dl() was misbehaving on threaded servers... aren't some FastCGI things multi threaded? Derick

Sascha Schumann

22 years ago
On Wed, 11 Feb 2004, Derick Rethans wrote:
> On Wed, 11 Feb 2004, Sascha Schumann wrote: > > > On Wed, 11 Feb 2004, Derick Rethans wrote: > > > > > On Wed, 11 Feb 2004, Pierre-Alain Joye wrote: > > > > > > > - CLI/CGI (as pointed by Derick, but being wrong while saying (fast)cgi > > > > is slow ;) ) > > > > > > No, CGI is slow and for FastCGI dl() is a problem again. > > > > Why would dl() be a problem for FastCGI? > > dl() was misbehaving on threaded servers... aren't some FastCGI things > multi threaded?
No, not even on Windows. - Sascha

Jani Taskinen

22 years ago
On Wed, 11 Feb 2004, Pierre-Alain Joye wrote:
> >I feel this problem in the same way as the auto* tools. Each time >someone came in and say: "got errors using version x", "we" answer >please use the(damn old) version 2.x or whatever. As most of other >applications use recent auto* tools without problem.
Our codebase is much larger than any other plus we 'misuse' the auto* tools. :) Feel free to bring the stuff up-to-date so we actually COULD update to latest libtool/autoconf, etc. I looked at this once and decided it wasn't worth the effort.. Just use the snapshots if your auto* tools don't work. :) (autoconf > 2.13 is slow too. And the generated configure is REALLY slow. Not to forget the fact that the versions I tested are also buggy in some cases, can't remember right now in what way and too busy to actually test again) --Jani

Pierre-Alain Joye

22 years ago
Organization: Freelancer X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Organization: Freelancer X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 11 Feb 2004 18:10:40 +0200 (EET) Jani Taskinen <sniper@iki.fi> wrote:
> Our codebase is much larger than any other plus we 'misuse' > the auto* tools. :) Feel free to bring the stuff up-to-date so > we actually COULD update to latest libtool/autoconf, etc. > I looked at this once and decided it wasn't worth the effort..
I used the auto* tools as a sample of another similar case :). Note I'm not an expert of auto* as you seems to be, and only wondering why it does not work. Is it another good reason to delay the php5 release and fix it? It seems we are all busy as hell, and many "bugs" are left due to this fact. What do you mean by 'misuse'? maybe some informations/tips can help to get fixes? I can give it a try in 2 or 3 weeks, not before and absolutely no warranty. I'm only a poor user of these tools ;).
> Just use the snapshots if your auto* tools don't work. :)
I use CVS for now ;)
> (autoconf > 2.13 is slow too. And the generated configure is > REALLY slow.
lol who cares? Do you generate a configure every hour?
> Not to forget the fact that the versions I tested are also buggy in > some cases, can't remember right now in what way and too busy to > actually test again)
Could help if you remember these issues :) pierre

Sascha Schumann

22 years ago
> not an expert of auto* as you seems to be, and only wondering why it > does not work.
- autoconf 2.50 is six times slower. Which in turn means that developing with it takes 6 times longer (think of edit, compile, run cycle. Yeah, someone wrote that build system with a couple thousand LOC) - limited support of m4 command set. We use some commands such as esyscmd which are supposedly unsupported by the newer autoconf tools (or as the main autoconf guy puts it "It was never supported!!!! Read the documentation!!!!"). We work around that by trashing the autoconf cache every time.
> lol who cares? Do you generate a configure every hour?
Try "per minute" and you get close. - Sascha

Jani Taskinen

22 years ago
On Wed, 11 Feb 2004, Pierre-Alain Joye wrote:
>Jani Taskinen <sniper@iki.fi> wrote: > >> Our codebase is much larger than any other plus we 'misuse' >> the auto* tools. :) Feel free to bring the stuff up-to-date so >> we actually COULD update to latest libtool/autoconf, etc. >> I looked at this once and decided it wasn't worth the effort.. > >I used the auto* tools as a sample of another similar case :). Note I'm >not an expert of auto* as you seems to be, and only wondering why it >does not work. Is it another good reason to delay the php5 release and >fix it? It seems we are all busy as hell, and many "bugs" are left due >to this fact.
Delay it another year? Then maybe. :) I'm sure not gonna spend my precious time with this non-issue as the versions we rely on work fine.
>What do you mean by 'misuse'? maybe some informations/tips can help to >get fixes?
Sascha propably can explain better, I remember that the auto*/libtool developers once said we use the tools wrong or something like that. :)
>> (autoconf > 2.13 is slow too. And the generated configure is >> REALLY slow. > >lol who cares? Do you generate a configure every hour?
Yes, I generate it quite often. And my machine isn't the fastest in the world so for me it's an issue if generating configure takes very long time..here are quick'n'dirty benchmarks: Latest auto*/libtool: # time ./buildconf real 1m28.287s user 1m22.080s sys 0m5.710s "Old" auto*/libtool: # time ./buildconf real 0m18.772s user 0m15.750s sys 0m5.350s Running ./configure only takes about 20s more with new tools, so that's not so big issue.
>> Not to forget the fact that the versions I tested are also buggy in >> some cases, can't remember right now in what way and too busy to >> actually test again) > >Could help if you remember these issues :)
I have no time nor interest in testing it all again.. --Jani