Asynchronous operation and krb5 dependencies

Nathaniel McCallum npmccallum at redhat.com
Mon Jun 6 08:50:46 EDT 2011


On Mon, 2011-06-06 at 05:46 -0500, Nico Williams wrote:
> On Fri, Jun 3, 2011 at 1:37 PM, Nathaniel McCallum
> <npmccallum at redhat.com> wrote:
> > 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()...
> 
> I think the solution is simple: let the highest layer provide an event
> loop handle in the form of a set of libevent-like (same prototypes,
> basically) function pointers and even base pointer.
> 
> (Well, but then, how do you deal with APIs like the GSS-API where
> there's no obvious way to reference any particular context due to the
> lack of a krb5_context-like argument?)

This is exactly what we are doing, with a wrapper library.

GSS-API is largely unrelated (for now) since it will just have to
continue using the synchronous apis.  When GSS-API becomes async, it can
use libverto.

Nathaniel




More information about the krbdev mailing list