[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-29 18:31:19
[Download RAW message or body]

   Date: Thu, 29 Aug 2002 15:26:33 -0300
   From: Henrique de Moraes Holschuh <hmh@debian.org>

   Moving thread to SASL ML...

really this time.

   On Thu, 29 Aug 2002, Lawrence Greenfield wrote:

   > There are some things that need global state (for instance,
   > dlopen()ing the modules modifies global state). It is impossible for

   Hmm... The real problem is that when coupled to NSS modules, the application
   really has absolutely no idea whatsoever about what the system is trying to
   do.  Offloading this to the app simply won't be possible.

   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.

   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().

Larry

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