Asynchronous operation and krb5 dependencies

[Greg Hudson]

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.

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:

  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.

The situation we're in right now with asynchronous programming is
similar to how things were before the system pthreads library was the
obvious and only answer to programming with threads under Unix.  If you
used a library in an application, it wasn't enough for the library to be
using just any threads implementation; it had to be using the same one
as you were.  I don't think krb5 ever made run-time allowances for using
different threading primitives, but it wasn't unheard of; you can see
goop like that in OpenSSL, for instance.