So in the longer term, is there a reason the parent has to contain the
interpreter at all? Can't it just do a system call when it needs one?
It seems a bit excessive to put aside a couple of megabytes of system
memory just to run startup.pl.
Well, remember that the interpreter itself
Hi there,
On Fri, 21 Jan 2000, Stephen Anderson wrote:
So in the longer term, is there a reason the parent has to contain the
interpreter at all? Can't it just do a system call when it needs one?
Well, remember that the interpreter itself will remain shared
throughout, so there's no
Hi all,
On Wed, 19 Jan 2000, Gerald Richter wrote:
in the long term, the solution that you have prefered in previous
mail, not to unload modperl at all, maybe the better one
As I understand it with Apache/mod_perl:
1. The parent (contains the Perl interpreter) fires up, initialises
-Original Message-
From: Gerald Richter [mailto:[EMAIL PROTECTED]]
Sent: 19 January 2000 04:36
To: Alan Burlison; [EMAIL PROTECTED]
Subject: RE: Why does Apache do this braindamaged
dlclose/dlopen stuff?
So I would agree to your last sentences that Dynloader is responsible
On Tue, Jan 18, 2000 at 08:03:42PM +, Alan Burlison wrote:
I think the correct fix is for the Apache core to avoid dlclosing
anything it has dlopened in the first place. If new modules have been
added to the config files, they should be dlopened, but any old ones
should *not* be
Can someone please explain why Apache does all the dlclosing and
dlopening of shared files on startup and a restart? I can think of no
reson why this would ever be necessary - why on earth is it done?
Alan Burlison
On Tue, Jan 18, 2000 at 12:59:13PM +, Alan Burlison wrote:
Can someone please explain why Apache does all the dlclosing and
dlopening of shared files on startup and a restart? I can think of no
reson why this would ever be necessary - why on earth is it done?
Alan Burlison
Probably
Can someone please explain why Apache does all the dlclosing and
dlopening of shared files on startup and a restart? I can think of no
reson why this would ever be necessary - why on earth is it done?
I don't know, but I know for sure that causes a lot of trouble with mod_perl
and Perl
Probably the biggest reason for dlopen/dlclose on a restart is that the
list of modules in the config file can change on a restart. The reason
for the reload on startup has something to do with parsing the config
file in the parent and child; it was never adequately explained to me.
The
On Tue, Jan 18, 2000 at 02:40:59PM +0100, Gerald Richter wrote:
Probably the biggest reason for dlopen/dlclose on a restart is that the
list of modules in the config file can change on a restart. The reason
for the reload on startup has something to do with parsing the config
file in the
That is what my patch did. And that was the explanation I posted of
the problem last week when we were debugging it.
Sorry, I missed that thread. I have posted this problem more then once here,
because it have beaten me and other often when using Embperl. The problem
there is often more
On Tue, Jan 18, 2000 at 08:26:17PM +0100, Gerald Richter wrote:
Also I didn't tried it yet, your patch makes much sense too me. I will try
it out as soon as I get a litle free time. The next step is to port it NT,
because there isn't a dlopen/dlclose (of course there is one, but with a
Vivek Khera wrote:
AB To summarise: Apache dlclose's the mod_perl.so, which then results in
AB the perl libperl.so being unloaded as well (there's a linker dependency
Excellent summary... thanks!
AB from mod_perl - perl libperl.so). Unfortunately the perl XS modules
AB loaded in
On Tue, Jan 18, 2000 at 08:03:42PM +, Alan Burlison wrote:
The current fix is to forcibly unload the perl XS modules during the
unload. However, on reflection I'm not at all sure this is the correct
thing to do. Although you can unload the .so component of a perl
module, you can't
To summarise:...
Thanks for the summary, but I already know this problem for a long time and
I am very happy that somebody has taken the time track this down and provide
a solution :-)
However, other folks have reported the exact same problem on other OSs,
eg Linux BSD, so I think that in
Daniel Jacobowitz wrote:
On Tue, Jan 18, 2000 at 08:03:42PM +, Alan Burlison wrote:
The current fix is to forcibly unload the perl XS modules during the
unload. However, on reflection I'm not at all sure this is the correct
thing to do. Although you can unload the .so component of
Gerald Richter wrote:
That's the same on NT. It seems to occur on all OSs, so it won't help
anything to make the linker responsible, there are to much linkers... and I
am not sure if the linker can know under all circumstances which libraries
to unload.
Yes it can. Its main job is to keep
Yes it can.
No it can't :-)
Its main job is to keep track and control the dependencies
between libraries. It's just that sometimes thy don't do a particularly
good job of it ;-)
This works only if this dependencies are know at link time, but look at the
source of Dynloader. You can
On Tue, Jan 18, 2000 at 10:19:04PM +0100, Gerald Richter wrote:
Yes it can.
No it can't :-)
Its main job is to keep track and control the dependencies
between libraries. It's just that sometimes thy don't do a particularly
good job of it ;-)
This works only if this
You're confusing the dynamic and static linkers. The dynamic linker is
what he was referring to; it knows what libraries it resolves symbols
to.
Yes, I know this difference and you will be right in most cases, but the
address that is returned, could be passed around to other libraries and
On Tue, Jan 18, 2000 at 10:43:09PM +0100, Gerald Richter wrote:
You're confusing the dynamic and static linkers. The dynamic linker is
what he was referring to; it knows what libraries it resolves symbols
to.
Yes, I know this difference and you will be right in most cases, but the
Gerald Richter wrote:
This works only if this dependencies are know at link time, but look at the
source of Dynloader. You can retrieve address of any (public)symbol inside a
library dynamicly at runtime. Now you have the entry address and can pass it
around. No linker will ever have a
Alan Burlison wrote:
AB from mod_perl - perl libperl.so). Unfortunately the perl XS modules
AB loaded in during startup via dlopen are *not* unloaded, nor do they
AB succeed in locking the perl libperl.so into memory (you could construe
AB this as a linker bug). Then Apache reloads the
Actually, I retract that statement. It is *not* a linker bug. By
explicitly adding a dependency between the XS .so modules and the perl
libperl.so, the problem can be made to dissapear, as ld.so then knows
that there is a dependency between the XS module and the perl libperl.so
I think
24 matches
Mail list logo
