adding DSO support to the MPE/iX port (module API questions)

["BIXBY,MARK (HP-Cupertino,ex1)" <ma...@hp.com>]

Hi new-httpd,

I'm currently working on freshening up the HP MPE/iX port of Apache, as well
as providing DSO support for the first time.

MPE lacks dlopen/dlsym/dlclose, so I had to write some stubs to attempt the
equivalent functionality using native MPE loader intrinsics.  It was fairly
easy to do dlopen and dlsym, but dlclose is a problem because there's no
documented/supported end-user way on MPE to unload a previously loaded
library.

This caused a problem when I attempted to start httpd.  The DSO modules
would all load correctly via dlopen/dlsym for the first configuration pass,
and all of the module commands in httpd.conf would parse OK.  But httpd then
dlcloses everything, and does a second configuration pass after doing
another round of dlopen/dlsym on the DSO modules.  This time the modules
weren't being added to the active list, and commands like "Order" were being
flagged as syntax/mis-spelling errors.

Because I can't currently do a real unload on a dlclose, when the modules
were reloaded during the second pass, the previously loaded (and modified)
global data was reused instead of being reinitialized by a genuine reload.
Further investigation revealed that it was the "module_index" and "next"
fields of the STANDARD_MODULE_STUFF portion of the module struct that were
causing the syntax error problem, and once I modified my dlclose stub to
reinitialize those fields to -1 and NULL respectively, the modules now load
and get recognized properly during the second pass and the syntax error
problem disappeared.

This solves the reinitialization problem with respect to the module struct,
but I have no way of reinitializing any private module global data items.
I've read the API documentation and looked at mod_example and both sensibly
make the point that you want to use pools for your working data, and if a
module strictly does that, it should be functional in the no-reload MPE
environment.  But neither place explicitly addressed the question of
implicitly initializing global private data via the library load/reload
process.

So the bottom line question I need answered is are modules allowed expect
that global private data initialized with compile-time constants will be
reinitialized when the module is reloaded (bad for MPE)?  Or are modules
supposed to take care of data initialization in the init() handler (good for
MPE)?

If modules are allowed to depend on library reloads reinitializing their
global private data, then I'll have to do more research into possibly using
privileged internal MPE loader functions to force a genuine unload (if such
functions even exist and are safely callable by end-user programs).

Thanks....

- Mark Bixby