Asynchronous operation and krb5 dependencies

Nathaniel McCallum npmccallum at redhat.com
Fri Jun 3 14:37:30 EDT 2011


On Fri, 2011-06-03 at 11:59 -0500, Nico Williams wrote:
> You're saying that the answer to DLL hell is to have libraries with
> different names and different symbl naming even when they serve much
> the same purposes.
> 
> That's one answer to DLL hell; there are others.  But at least now
> we've stated that DLL hell is the real problem.  Or I've stated that
> -- maybe you could confirm it :)

This is not a DLL hell problem.  The problem is that exposing a
particular event loop in your public api means that at run time you are
locked into using that event loop (aside from using hacks like
LD_PRELOAD).  This means that your library is incompatible with every
application that chooses another event loop.

The solution is simple. Your average library requires only a small
subset of what each event loop provides. If you can provide a *run-time*
wrapper which provides this small subset, you can make public api's
asynchronous without having to choose an event loop for your
applications.  This has nothing to do with DLL hell, unless you know of
a way to do lazy symbol loading during exec()...

Nathaniel




More information about the krbdev mailing list