Asynchronous operation and krb5 dependencies

[Nico Williams]

On Mon, Jun 6, 2011 at 9:17 AM, Greg Hudson <ghudson at mit.edu> wrote:
> 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?)
>
> For the purposes of libkrb5, we're taking the view that an application
> will only need one main loop implementation.  (It may need multiple
> instances of the main loop, but we're not trying to support an
> application which uses libevent in one thread and g_main_* in another.)
> So, when the application provides its vtable to libverto, that will get
> stored in global process state and used for all async operations--no
> need for a context.

I object to this.  Sam's already stated the reasons that I would
state.  Specifically I'm objecting to global state.

If you use the libevent function prototypes that take an event base
pointer as an argument, then you can avoid the need for global state.

A single event loop is a fine assumption on some operating systems,
but not on all.  It's likely wrong in the case of layered software, as
Sam points out.

> I don't know if that will be acceptable for GSSAPI, since we don't
> control it.  If GSSAPI goes in a different direction--say, providing the
> async vtable to every async call--that's fine; we'll just invoke the
> specified async functions from libgssapi_krb5 in preference to libverto.

Is the GSS-API the motivation for having this be global state?

Nico
--