Asynchronous operation and krb5 dependencies

[Nico Williams]

On Fri, Jun 3, 2011 at 11:01 AM, Greg Hudson <ghudson at mit.edu> wrote:
> On Fri, 2011-06-03 at 11:31 -0400, Nico Williams wrote:
>> I don't get the need for a wrapper library for async I/O -- libevent
>> is such a library, and one can easily implement libevent-compatible
>> wrappers around alternative event loops.  Or was that what you were
>> proposing?
>
> libevent is not, to my knowledge, an event loop wrapper library; it's an
> event loop implementation with a number of internal back ends for event
> signalling.  You can't tell libevent to forward operations (like adding
> a read callback for a socket) to g_main_* or libdispatch or whatever.

Libevent is not a wrapper.  But you can make a wrapper with the same
libevent API -- that's my point.  Why invent yet another async I/O API
just because you feel the need to write a wrapper around multiple
distinct event loops?

> Someone could write an libevent-ABI-compatible wrapper around g_main_*;
> a number of libraries have done so.  But that's not enough.  Imagine
> yourself in the role of operating system distributor, trying to package
> all of the following components:

OK, so you get what I meant :)

>  libevent
>  krb5
>  an application using g_main_* and krb5
>  an application using libevent and krb5
>  an application using libdispatch and krb5
>
> How do you get every application to use the (hypothetical, future)
> asynchronous libkrb5 APIs such that they each register their callbacks
> with the correct event loop?  That's what libverto is for.

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

Other answers to DLL hell include:

 - thin wrappers should be statically linked (why not?  being thin the
code duplication involved is too small to care about, and as for
patching, being thin also means a lower likelihood that you'll need to
patch the wrapper library);

 - RTLD_GROUP (on platforms where it is available);

 - static linking of all DLL hellish things, not just wrappers (for
example, the SQLite3 community insists on static linking of
libsqlite3; when I was at Sun/Oracle I objected to that approach, but
towards the end I softened my stance);

 - something else?

Nico
--