[16866] in Kerberos_V5_Development
Re: Asynchronous operation and krb5 dependencies
daemon@ATHENA.MIT.EDU (Nico Williams)
Wed Jun 8 15:24:43 2011
MIME-Version: 1.0
In-Reply-To: <1307369874.2281.83.camel@t410>
Date: Wed, 8 Jun 2011 14:24:38 -0500
Message-ID: <BANLkTinbNSuAbCVDa-TH1=5xJb13TNNDag@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Greg Hudson <ghudson@mit.edu>
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Mon, Jun 6, 2011 at 9:17 AM, Greg Hudson <ghudson@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 wouldstate. Specifically I'm objecting to global state.
If you use the libevent function prototypes that take an event basepointer 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, asSam 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--
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
