[PATCH][saslauthd] cyrus-sasl-2.1.10/saslauthd credential caching

[Rob Siemborski]

On Wed, 15 Jan 2003, Jeremy Rumpf wrote:

> Round 3 now has:
>
>  cache_lookup()
>  cache_commit()
>  cache_discard()

I'm guessing a failure to call cache_discard() just results in a memory
leak and nothing worse (since you are preserving state from cache_lookup
to cache_commit)?

> > Wasn't this originally going to use libmm?
> >
>
> My knowledge on libmm is brief (quick reading today),
>
> Saslauthd already depends on fcntl() being there natively.

Sure.

> If I understand correctly, libmm only does shm segment level locking. I'm not
> sure what the perf differences would be between per bucket level locking via
> fcntl() and table level locking via fcntl(). Since fcntl() is required by
> saslauthd, I went with per bucket level locking.
>
> libmm introduces another dependency (including autconf checks), unless libmm
> would be distributed with the saslauthd package. I originally thought it
> beneficial to keep any additional dependencies down if a good alternative
> could be presented.

Its unclear to me how standard the shared memory APIs are on more esoteric
unixes anyway, so I'm pretty sure we want autoconf checking for this
functionality as it is.  The advantage of libmm is that we only need to
check for libmm (and disable caching if its not there), instead of trying
to cope with all the potential portability problems (which, presumably,
libmm has solved).

> Plus, all in all, it sounded pretty challenging. Haven't done any hard core
> coding in awhile :).

I can definately appreciate that.

> Yes, I've started to addresses this to. I've broken out the memory allocation
> so that the unix IPC method will use a shared memory segment, while the doors
> IPC method would stick with a malloc'd segment. The doors IPC method will
> retain the fcntl() based locking for the malloc'd segment. I have some
> reading up to do on doors IPC (is it thread based?).

Yes.  I'm not sure fcntl() locking is good enough within a single process.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper