Re: KITTEN: IETF 75 - 76

[Jeffrey Hutzelman <[e-mail]>]

--On Wednesday, September 02, 2009 05:20:15 PM -0400 Michael B Allen 
<[e-mail]> wrote:

> 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;
>> > }

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.