Asynchronous operation and krb5 dependencies

[Sam Hartman]

>>>>> "Greg" == Greg Hudson <ghudson at MIT.EDU> writes:

    Greg> On Mon, 2011-06-06 at 06:46 -0400, Nico Williams wrote:
    >> (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?)

    Greg> For the purposes of libkrb5, we're taking the view that an
    Greg> application will only need one main loop implementation.  (It
    Greg> may need multiple instances of the main loop, but we're not
    Greg> trying to support an application which uses libevent in one
    Greg> thread and g_main_* in another.)  So, when the application
    Greg> provides its vtable to libverto, that will get stored in
    Greg> global process state and used for all async operations--no
    Greg> need for a context.

I'm kind of uncomfortable with the idea that an application will only
need one main loop implementation.
krb5 tends to get called from things like nss plugins, sasl interfaces
to other applications, etc.

If the main application is asynchronous then it mostly will have one
event loop.
The only exception is if you can get some sub-component with its own
event loop to tell you what file descriptors and timeouts it cares
about, then you can backend one event loop into another.

However if there are parts or threads of the application that are
synchronous, those parts can easily have their own event loops for
semi-asynchronous operation.  For example, krb5 could do such a thing to
speed up the interactions between DNS resolution and KDC contacting
within the synchronous APIs.

For this reason, I do not think the one-event-loop-per-application
assumption is sound.

--Sam