Asynchronous operation and krb5 dependencies

[Nico Williams]

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?)

Nico
--