Date: Wed, 11 Feb 2004 14:02:41 +0200
To: Pierre-Alain Joye pierre@pearfr.net
From: Andi Gutmans andi@zend.com
Subject: Re:dl()problem
Cc: Pierre-Alain Joye paj@pearfr.org,zeev@zend.comPierre,
dl() should have been deprecated a long time ago.
It's not secure (for example on a shared server where you don't have
access to php.ini), it's slow and it doesn't work in multi-threaded
environments.
Besides that there are many chicken&eggs problems withdl()and we don't
feel it's worth screwing up the Zend/PHP source code just to work around
such problems.Andi
At 12:59 PM 2/11/2004 +0100, Pierre-Alain Joye wrote:
On Wed, 11 Feb 2004 13:47:43 +0200
Andi Gutmans andi@zend.com wrote:Pierre,
We looked at the problem. It is not very fixable and as
dl()should bedeprecated anyway we'll keep things the way they are.
You should really load .so files via php.ini both for performance and
stability reasons.Deprecate
dl()is not the way.Performance is not in cause here or not in the way you think.
Then it is not always possible to alter the global php.ini, ie when only
some sections of a host will use an extension (here the performance
problem is the counter of what you think).I do not care that much about the debug&dl issue, but not about dl. dl
is one of the functions that makes php flexible, we have to keep it,
imo.I hope we can find a solution,
thanks for your work,
regards,
pierre
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:
Date: Wed, 11 Feb 2004 14:02:41 +0200
To: Pierre-Alain Joye pierre@pearfr.net
From: Andi Gutmans andi@zend.com
Subject: Re:dl()problem
Cc: Pierre-Alain Joye paj@pearfr.org,zeev@zend.comPierre,
dl() should have been deprecated a long time ago.
It's not secure (for example on a shared server where you don't have
access to php.ini), it's slow and it doesn't work in multi-threaded
environments.
Besides that there are many chicken&eggs problems withdl()and we don't
feel it's worth screwing up the Zend/PHP source code just to work around
such problems.Andi
At 12:59 PM 2/11/2004 +0100, Pierre-Alain Joye wrote:
On Wed, 11 Feb 2004 13:47:43 +0200
Andi Gutmans andi@zend.com wrote:Pierre,
We looked at the problem. It is not very fixable and as
dl()should bedeprecated anyway we'll keep things the way they are.
You should really load .so files via php.ini both for performance and
stability reasons.Deprecate
dl()is not the way.Performance is not in cause here or not in the way you think.
Then it is not always possible to alter the global php.ini, ie when only
some sections of a host will use an extension (here the performance
problem is the counter of what you think).I do not care that much about the debug&dl issue, but not about dl. dl
is one of the functions that makes php flexible, we have to keep it,
imo.I hope we can find a solution,
thanks for your work,
regards,
pierre
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 thatdl()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
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
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
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 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