Re: KITTEN: IETF 75 - 76

[Nicolas Williams <Nicolas.Williams at sun.com>]

On Thu, Sep 03, 2009 at 11:17:49AM -0400, Michael B Allen wrote:
> On Thu, 03 Sep 2009 10:38:49 -0400
> Jeffrey Hutzelman <jhutz at cmu.edu> wrote:
> > > There is another model:
> > >
> > >> > while (1) {
> > >         gss_process_events(&minor, ...);
> > >> >
> > >> > 	ret = gss_call(&minor, GSS_C_NOWAIT, ...);
> > >> > 	if (ret != 0 && minor == EAGAIN) {
> > >> > 		continue;
> > >> > 	}
> > >> > 	...
> > >> > 	break;
> > >> > }
> > 
> > That's not another model.  That's equivalent to using the synchronous form 
> > of the call, if gss_process_events() blocks until the mech is ready to be 
> > called, or to polling, if it eventually times out.
> 
> But there only needs to be one caller of gss_process_events for any
> number of NOWAIT calls. So you can build event loops with it. I'm not
> sure I understand the callback model being discussed but it seems to
> be an event loop powered by a separate thread firing callbacks in
> response to changes in status of calls. If that is in fact the case,
> you could build the callback model you're talking about using only the
> NOWAIT flag model I'm talking about.

It may be reasonable to have libraries use an externally provided event
API (an alternative offered by Volker Lendecke).  (A callback model with
async-signal-safe callback functions will effectively do just that.)

It is not reasonable to have libraries provide an event loop for
applications to use.  The reason is as I've explained before.

Try putting together an application (and libraries) that uses:

 - an LDAP library, which uses a SASL library, which, through a plug-in,
   uses a GSS-API library, and through the GSS-API there's the Kerberos
   V5 GSS-API mechanism, which in turn might use a pluggable crypto
   lubrary, ...

 - also uses the GSS-API/SASL/crypto directly and independently of the
   LDAP library

Now, just for fun, add PKCROSS into the picture, deep in the bowels of
the krb5 mech.

If each library wants to have its own event loop then each one had
better provide a way for the caller to use that event loop for other
purposes, else there's no way to construct such an application and
libraries without resorting to threads.  Now say that each library does
provide a way for the caller to use the library's event loop, then each
layer in the above stack will have to do just that.

Once you've built that monstrosity there'll only be one thing left to
do: debug it!  ;)

That kind of complexity is a non-starter.  It's much easier to just wrap
a thread around any synchronous and slow operation that I want made
asynchronous.

Still, if you want to write an Internet-Draft outlining your proposal,
we'll review it.

Nico
--