[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cyrus-sasl
Subject:    Re: My Take on Virtdomains so far
From:       Lawrence Greenfield <leg+ () andrew ! cmu ! edu>
Date:       2002-08-30 21:09:15
[Download RAW message or body]

   From: "Howard Chu" <hyc@highlandsun.com>
   Date: Fri, 30 Aug 2002 13:28:59 -0700

   I don't understand the problem. OpenLDAP uses pthread mutexes and
   Berkeley DB uses its own atomic test-and-set spinlocks. There's no
   problem with mutexes being ignored, even though two different
   implementations are in use at one time. Whatever approach SASL uses
   internal to itself to serialize its own processing is invisible to
   outside callers.

No, it's not. Actually, Berkeley DB has the same issues: it has a way
to decide at compile-time what sort of mutexes are used and various
interoperation problems with the test-and-set spinlocks. This means
that an application using some threading models (for instance, the
threading package used in AFS) can't depend on a pre-compiled version
of Berkeley DB, since the locking methods might be incompatible.

Some of the better known conflicting threading models from Posix
pthreads are the Java green threads and the GNU Pth threading
library. 

[...]
   > The alloc model is pretty much self-contained but it's bad if the
   > application switches it after initializing the library. With any
   > hope, any library that calls libsasl never calls
   > sasl_set_alloc().

   There would have been no need for sasl_set_alloc if you had simply
   provided a sasl_free() to allow callers to dispose of
   sasl-allocated storage.

There's never any need for an application to dispose of sasl-allocated
storage in Cyrus SASL version 2. Each datatype has its own dispose
functions.

The alloc functions are simply there as a convience for application
writers (who might not want to deal with SASL_NOMEM errors or might
want to allocate SASL memory in a special arena, whatever).

Larry

[prev in list] [next in list] [prev in thread] [next in thread]