Re: Docs and 2.1.27 and threads

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On ti, 18 syys 2018, Jan Parcel wrote:
I have not had time to look at all the docs to see what changed, but we have had a problem here with a multi-threaded program calling sasl_client_init multiple times in parallel and getting crashes and hangs.

I've found various comments inside code and on the web about which routines are vs. are not thread-safe, including that the sasl_set_* routines are not, but I have not seen anything
that says "make sure you don't have parallel calls to sasl_client_init"

Can there be some kind of note somewhere about thread safety?

Sometime, if I have time, I will be trying to make sasl_client_init thread-safe if possible, probably using static pthread locks (in a library, static locks are the ONLY way to guarantee no parallel mutex lock creation, which is a big no-no) but I got stuck on a non-sasl customer issue which might take me a long time.
It used to be not possible to run SASL server and SASL client in the
same application at the same time with GSSAPI plugin as it was using the
same static lock for both. I changed that to use per-context locks. As
long as you are not sharing the same SASL context among multiple threads
with GSSAPI, there shouldn't be a problem. GSSAPI itself is blocking but
Cyrus-SASL will not block threads working on different SASL contexts.

This cannot be extended to other plugins. digestmd5 uses a single
reauth cache entry lock shared among all contexts. krb4 deals with
non-threaded kerberos4 library and thus has a single static lock. It is
mostly dead as krb4 is quite rare to see in real life. Other plugins
don't use locking at all.

/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[Index of Archives]     [Info Cyrus]     [Squirrel Mail]     [Linux Media]     [Yosemite News]     [gtk]     [KDE]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux