[16862] in Kerberos_V5_Development
Re: Asynchronous operation and krb5 dependencies
daemon@ATHENA.MIT.EDU (Sam Hartman)
Tue Jun 7 14:08:29 2011
From: Sam Hartman <hartmans@mit.edu>
To: Greg Hudson <ghudson@mit.edu>
Date: Tue, 07 Jun 2011 14:08:21 -0400
In-Reply-To: <1307369874.2281.83.camel@t410> (Greg Hudson's message of "Mon,
06 Jun 2011 10:17:54 -0400")
Message-ID: <tslaadt5xbe.fsf@mit.edu>
MIME-Version: 1.0
Cc: Nico Williams <nico@cryptonector.com>, "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
>>>>> "Greg" == Greg Hudson <ghudson@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
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
