| Subject: | improve thread safety of gss wrap/unwrap functions |
As discussed recently on both kerberos@mit and krbdev@mit, it'd be nice if the wrap/unwrap
type functions could operate in multiple threads without application-level locking.
Specific use cases:
* multiple threads operating on messages on an unsequenced message stream
* a sequenced message stream treated as full-duplex with two threads (e.g., http://www.openldap.org/lists/openldap-technical/200802/msg00121.html)
Oh, and document it.
The krb5 mechanism data includes two sequence numbers, a krb5_context, and a
krb5_auth_context.
type functions could operate in multiple threads without application-level locking.
Specific use cases:
* multiple threads operating on messages on an unsequenced message stream
* a sequenced message stream treated as full-duplex with two threads (e.g., http://www.openldap.org/lists/openldap-technical/200802/msg00121.html)
Oh, and document it.
The krb5 mechanism data includes two sequence numbers, a krb5_context, and a
krb5_auth_context.