Following up on my recent post to [vchkpw], I did some digging back into
the history of the shared libvpopmail patch and the discussions
surrounding it, and have the following thoughts.

First off, let me prefice this by saying that while I understand the
concept of shared libraries, I don't understand the underlying mechanics
of how the OS handles them, and thus am not sure exactly how can be
affected performance-wise.  That being said, here's my thoughts:

1) A shared library with a stable API would make recompiling outside
programs (e.g., QmailAdmin) unnecessary, which would be a Good Thing(tm).
2) There has been some question regarding performance of the vpopmail
programs when compiled against shared vs. static libraries.  I suggest the
following options be added for shared libraries at compile-time:
  a) --disable-shared - don't build, which is what vpopmail
does now.
  b) --enable-shared - build, but don't link the vpopmail
binaries against it - this gives other programs the ability to use the
shared library, but keeps the vpopmail binaries statically linked.
  c) --enable-shared-binaries - build and link the vpopmail
binaries against it.  Implies --enable-shared.
  d) possibly, if it's not to difficult, have a --enable-shared-binaries=
and/or --enable-static-binaries= option, which takes a list of binaries
to link against the stated library, and links the rest against the
other.  So you could have static vdelivermail and vchkpw, but not
vadduser, for example.  Not sure if that really is necessary, but static
linking does save space...
3) In all cases, even if the vpopmail binaries are linked against the
shared library, the static library libvpopmail.a should be built since
some programs expect it.

Also, just a supposition on my part, but if you're running (e.g.)
courier-authdaemon linked against all the time, wouldn't
that (theoretically) mean that other dynamically linked vpopmail programs
would run faster than the static version since the library would already
be loaded in memory?  If so, perhaps the speed solution for a dynamic
(e.g.) vdelivermail would be to run something that was dynamically linked
all the time, so libvpopmail stayed in memory...

Anyway, that's it for now - I haven't even tried the patch against the
latest vpopmail, though I'm guessing it should be fairly easy (albeing
possibly tedious) to integrate since it's not much in the way of actual
code changes...


Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
  - Layman's translation of the Laws of Thermodynamics

Reply via email to