Re: KITTEN: IETF 75 - 76

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

On Tue, Aug 18, 2009 at 01:10:08AM +0200, Martin Rex wrote:
> > > hmm, is asynchronous calls related to exportable contexts perhaps...?
> 
> To me that sounds like barking up the wrong tree.
> 
> If an application does not want to get blocked, it should use
> seperate threads for the UI and other events that it does want
> to do in parallel.  The application should take care about
> and have control over each an every thread in a process.
> Having service APIs create additional threads invisible to
> the application will open a huge can of worms.

Of course that can be done, and that was my first response to Love.
However, implementors can well do better, in terms of efficiency, if
there are actual standard async variants of these.

To see why consider this: default stack sizes for threads can be quite
sizeable (e.g., 1MB in Solaris 32-bit, or 2MB in 64-bit).  An
application might have no idea how much stack space
gss_init/accept_sec_context() might need.

To be fair, a mechglue implementor who does the background thread thing
wouldn't necessarily know either, but chances are they will (one way or
another).  A mechglue and mechanism implementation where both support
the async functions might not even need anything more than a thread to
run a small I/O event loop, with tiny stack needs since all it'd do is
wait for I/O and call the application callback (which should probably
post an event to the application I/O loop).

> Maybe you want an API to specify timeouts after which a
> gssapi call should give up and return an error?  Ideally,
> that should already be configurable in an implementation specific
> fashion (but often is not).

That's not enough.  Nor is it necessary in the case where mechglue and
mechanisms support thread cancellation.  Of course, that's a very
OS-specific feature that the C bindings don't remotely address.  So yes,
a timeout parameter would be nice, but it's still not enough.