Docs and 2.1.27 and threads

[jan parcel]

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