Re: Docs and 2.1.27 and threads

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


Then it might be a good idea to ONLY lock sasl_client_init, and maybe only until the variable is set that it is already initialized.

What I was seeing was multiple threads calling sasl_client_init at the same time, thus running multiple copies of the early plugin loading that loads all plugins.  Since we provide multiple plugins (it is for the customer to configure which ones to use), it made a mess.  For now, the solution was to tell the caller "don't do that."

On 9/18/2018 11:32 AM, Alexander Bokovoy wrote:
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.

Jan Parcel, Software Developer
Oracle Systems Server & Cloud Engineering

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

  Powered by Linux