On Wed, 2004-03-24 at 09:08, Douglas E. Engert wrote: > Some situations which need to be addresed: > > o application may wish to use one thread model, but GSSAPI > implementation is using a different model.
In the long run, this is like saying "an application may wish to use one stdio implementation, but the GSSAPI implementation is using a different one." There's just no point in adding complexity for this purpose. In the short term, you're also deluding yourself if you think you can provide good support for non-standard threading implementations. libc functions, like gethostbyname(), already make use of the native threading primitives. See http://www.imc.org/ietf-sasl/mail-archive/msg01009.html for more discussion on this point. > o Applicatin may wish to use multiple mechs but the mechs > use differnet thread models. ... which is why platforms should provide one standard implementation (perhaps with multiple APIs, like on Solaris, but they must interoperate), and all libraries should use it. I believe platforms are pretty much all doing their side of the job correctly at this point. > Any thoughts on doing something like OpenSSL does with callbacks for threads? I think OpenSSL and cyrus-sasl went in the wrong direction here. What they do is really unfriendly to callers who are themselves thread-safe libraries. If one is dead-set on providing callbacks for non-standard thread implementations, a better model is glib's, where specifying alternate thread callbacks is optional (and rarely used). -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to [EMAIL PROTECTED]
