Re: KITTEN: IETF 75 - 76

[Michael B Allen <[e-mail]>]

On Wed, 2 Sep 2009 10:32:41 -0500
Nicolas Williams <[e-mail]> wrote:
> Absolutely no polling.
> 
> Async I/O is not rocket science.  We can quibble over details, but we've
> only got so many workable models.  And we have to be mindful that not
> one model will result in fully portable application code.
> 
> Here are some reasonable models:
> 
>  - Completion callback (or, rather, a callback indicating that there's
>    work to do, not necessarily completion)
> 
>    This implies either a threaded process model or an async I/O process
>    model with one common event loop provided by the OS.
> 
>    This model is the simplest for apps to use, and it will be portable
>    to Linux, *BSD, Solaris, Windows.  But not necessarily to embedded
>    devices, real-time OSes, etc...
> 
>  - Return handles to I/O resources that the app can feed into its event
>    loop.
> 
>    This is much more OS-specific.  On Unix/Unix-like OSes this means
>    returning an array of file descriptors.  On Windows it means
>    returning and array of file handles.  This too may not be terribly
>    portable.  And it requires that the application plug the returned
>    resources into its event loop, and take them out, on every call to
>    these GSS functions.

There is another model:

> > while (1) {
        gss_process_events(&minor, ...);
> > 
> > 	ret = gss_call(&minor, GSS_C_NOWAIT, ...);
> > 	if (ret != 0 && minor == EAGAIN) {
> > 		continue;
> > 	}
> > 	...
> > 	break;
> > }

The gss_process_events function would power the mechanism's event loop and wait for the status of an operation to change. Basically it would just call an implementation specific event loop without the 'loop'.

So there is no callback, it is not polling and it would be portable to pretty much any system because it does not require multiple threads / processes. You could juggle many GSS contexts with a single thread / process without breaking a sweat.

Note that I'm not necessarily advocating this technique. Currently I actually do something quite different for event loop stuff which seems to be the use-case we're talking about. There might be some horrendous flaw with it but I can't think of one at the moment.

Mike

-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/