Re: KITTEN: IETF 75 - 76

[Nicolas Williams <[e-mail]>]

On Thu, Sep 03, 2009 at 10:45:01AM -0400, Jeffrey Hutzelman wrote:
> Really, I think we have three options here:
> 
> 1) Assume POSIX threads(*).
> 2) Assume POSIX threads(*), but allow the existence of an implementation
>   dependent means of indicating use of some other threading model.

(2) is feasible.  You simply provide completion callbacks and say that
they must be async-signal-safe.

> 3) Recognize that there is no sane way to provide an portable async API
>   without either a portable threading model or a portable event model,
>   and give up.  Applications which want to call the GSS-API in an
>   asynchronous manner can simulate it by running the GSS-API call in
>   its own thread (under a platform-specific thread model).

4) Assume file descriptors and one or more of poll(), select(),
   /dev/poll, kevent, event ports, ...

Since (3) works today I'm very tempted to do nothing.

> (*) This means "you can't have this API unless you have threads".
> Unfortunately, it also means we're in the unenviable position of pushing
> an API which requires the use of threads but is not itself MT-safe.

The GSS-API is not inherently MT-unsafe.  Its MT-safety is not defined
-- _that_ is a problem.  (Should one lock around per-msg token functions
called with the same security context handle?)

Nico
--