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

List:       cyrus-sasl
Subject:    RE: My Take on Virtdomains so far
From:       "Howard Chu" <hyc () highlandsun ! com>
Date:       2002-08-30 20:28:59
[Download RAW message or body]

> -----Original Message-----
> From: owner-cyrus-sasl@lists.andrew.cmu.edu
> [mailto:owner-cyrus-sasl@lists.andrew.cmu.edu]On Behalf Of Lawrence
> Greenfield

>    Global state that is entirely self-contained to SASL, *and* has
> no effect on
>    transations ongoing on paralell is not a problem.  So, a list of the
>    available modules would not cause trouble.
>
> This isn't possible if we need something like mutexes, since those
> depend on what threading package you're using. Kerberos4 libraries
> aren't reentrant, so libsasl needs to mutex around calls to them.
>
> How do you propose setting the mutex type without application
> awareness? These mutexes have to be respected even if the application
> is using (say) both libldap and libimap and they both are doing k4
> authentications using libsasl.

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.
>
>    However, any sort of global state that is not completely
> self-contained to
>    SASL, such as the alloc model, is a killer.
>
> 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.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

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