Asynchronous operation and krb5 dependencies

[Simo Sorce]

On Tue, 2011-06-07 at 14:08 -0400, Sam Hartman wrote:
> >>>>> "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.

Absolutely right.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York