nss_winbind is not thread safe, any suggestions to fix this?

[boyang]

Jeremy Allison wrote:
> On Fri, Sep 28, 2007 at 11:49:47AM +0800, boyang wrote:
>   
>> hi, Allison:
>>      1. Could you explain the reason of renaming keep_response? I cannot
>> see any difference except it becomes more clear after the renaming.  In
>> my opinion, keep_response works properly without renaming them.
>>     
>
> No, it doesn't. It's actually a bug. A 'static int x' has file
> scope in C. All those variables were actually redefinitions of
> the same thing.
>   
hi, Allison:
    I think I cannot agree with you. the "static int keep_response" is
defined in functions, and it actually has function scope.
when gcc(4.1, the version of gcc I used) compile it, it will define
different symbols for each variable in different functions and those
symbols have different values(ie, different address, different memory). 
Take  keep_response as an example: actually in the binary file, four
different symbols are defined for keep_response. And it is the same for
response(static struct winbindd_response response)
which are defined in functions.

    77: 00006f88     4       OBJECT  LOCAL  DEFAULT   22 keep_response.6192
    78: 00006fa0   3240   OBJECT  LOCAL  DEFAULT   22 response.6190
    79: 000062d0     4      OBJECT  LOCAL  DEFAULT   22 keep_response.6223
    80: 000062e0  3240   OBJECT  LOCAL  DEFAULT   22 response.6221
    81: 00004ea8     4      OBJECT  LOCAL  DEFAULT   22 keep_response.6344
    82: 00004ec0  3240   OBJECT  LOCAL  DEFAULT   22 response.6342
    83: 000041fc     4       OBJECT  LOCAL  DEFAULT   22 keep_response.6380
    84: 00004200  3240   OBJECT  LOCAL  DEFAULT   22 response.6378

What is your opinion?

But anyway, there is no harm to rename them.


>   
>>      2. I can understand why you add pthread_mutex_lock/unlock
>> respectively in setpwent/setgrent and endpwent/endgrent.
>> But when I write the patch,  I take setpwent-getpwent-endpwent as one
>> object, and use pthread_mutex_lock in setXXent function,
>> pthread_mutex_unlock in endXXent function.  I think I have thought too
>> much about it :-).
>>      You are right. Respective pthread_mutex_lock/unlock operates normally.
>>     
>
> Thanks :-).
>
> Ok, thanks for the review. I'll commit.
>
> Cheers,
>
> 	Jeremy.
>
>