Re: KITTEN: IETF 75 - 76

[Martin Rex <[e-mail]>]

Nicolas Williams wrote:
> 
> > 
> > hmm, is asynchronous calls related to exportable contexts perhaps...?
> 
> No.  Think of how gss_init_sec_context() and gss_accept_sec_context()
> can go off and do things like: DNS lookups, TGS exchanges, certificate
> validation (including OSCP and/or CRL checking), ...  All those tasks
> must complete before those functions can return, but each of those tasks
> can take a long time to complete or fail to complete.
> 
> I.e., we want versions of gss_init/accept_sec_context() that will do as
> much work as they can, then return without necessarily completing their
> work, instead returning some completion event object so the application
> can wait for completion in its event loop.
> 
> The basic problem here are is that async APIs tend to be very
> OS-specific.  But I think we can still have an OS-agnostic design IF we
> can rely on background threads (i.e., on a multi-threaded process
> model).  Relying on bg-threads might not be feasible on systems where a
> multi-threaded process model can't be relied upon (well, on such systems
> the async functions can just always operate synchronously when called in
> a single-threaded process).

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.

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).


-Martin