httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew <>
Subject Re: mod_dld_elf
Date Tue, 05 Mar 1996 15:17:51 GMT
> This new dld_elf program, can anyone explain the theory behind it to me?
> It's above my head. 

The dld_elf module is a simple extension of the original mod_dld that
has been hanging about in the distribution (largely unused) for a
while now.  The idea is to separately compile the 'core server'
from the several funky module you might chose to use with Apache.

You can start the server running and then modify the configuration
files and send -HUPs to the server to make it reread the module
configuration.  The server responds by looking to see which additional
modules have been added to the run-time specification and then
linking them into place without halting the server.  The dl libraries
also allow whole modules to be removed, again following a HUP.
Removing modules at run-time, without downing the server is the
new functionality that is being exploited in this new version of
the module

There are probably may different ways this functionality can be
exploited, including:

1)	never having to down a server when you get hold of a new module
	that you want to play around with

2)	being able to tune the 'size' of the server - removing 
	unused modules to reduce the process size

3)	[rather exotic] making the server use a base level of modules 
	it always supports but then giving it the ability to load
	up extra modules to service certain requests, and then
	remove them immediately.  For example the mod_imap.c module
	would only be linked into the process image when someone clicked
	on an image.

	This doesn't sound as farfetched a procedure as it first
	seems.  Imagine in a years time, when the number of available
	modules has doubled, how much larger the server is going
	to be because of all the damned moules it has to support
	even though some of them are only gonna be used occassionally.

On my understanding of the dld module's present implementation
there is no facility which would allow the server itself to decide
which modules it needed, it still requires human intervention to
-HUP the beast following a change to the config.

Perhaps a way of registering the capabilities required of the server
for various URLs could be used, as in this fragment of imaginary

    # pages under /Projects/LargeUserbase are protected by a .htaccess
    # file that uses DBM authentication.  Any URL under there will need
    # modules supporting dbm authentication to be in place
    CapabilityRequired /Projects/LargeUserbase/ auth_dbm
    # We have a few image map files, let a module handle them
    CapabilityRequired *.map image_map

    # map real modules to the abstract capabilities they offer the
    # server
    CapabilityOffered auth_dbm_module auth_dbm
    CapabilityOffered imap_module image_map

Do you see how this sort of approach could let the server tune
itself given a few hints from the webadmin?

> <Aram>
> P.S. BTW, it doesn't compile.  Does it need anything other just being
> added to the Configuration file?

Hard to say.  It compiles on the author's (David Hankins) original
Linux platform (I watched him doing it) and it ports to FreeBSD by
changing a couple of parameters to dl library calls.  Off the top
of my head I recall BSDs not supporting the RTLD_LAZY parameter in
dlopen.  Changing such calls to:

    if( !(libhand = dlopen( filename, 1 )) ) 
	return dlerror();

worked fine.

I'm not aware of other changes needed to get it spinning on your
own platform, but it wouldn't hurt to mail the author directly,
he's pretty clued.


View raw message