svn commit: branches/uClibc-nptl/libc/misc/dirent

[Carmelo AMOROSO]

Mike Frysinger wrote:
> On Thursday 15 May 2008, Carmelo AMOROSO wrote:
>   
>> Mike Frysinger wrote:
>>     
>>> On Thursday 15 May 2008, Carmelo AMOROSO wrote:
>>>       
>>>> Mike Frysinger wrote:
>>>>         
>>>>> On Wednesday 05 December 2007, carmelo at uclibc.org wrote:
>>>>>           
>>>>>> Author: carmelo
>>>>>> Date: 2007-12-05 09:25:08 -0800 (Wed, 05 Dec 2007)
>>>>>> New Revision: 20626
>>>>>>
>>>>>> Log:
>>>>>> Fix opendir problem when statically linked due to a missing
>>>>>> initialization of the mutex field within DIR struct.
>>>>>> When linked dynamically instead, __pthread_mutex_init will
>>>>>> initialize the mutex itself. Without this fix, any call to
>>>>>> readdir will stuck forever trying to acquire the mutex.
>>>>>>             
>>>>> sorry, but i dont follow.  we call __pthread_mutex_init() on the
>>>>> dd_lock member of the dirent structure which should initialize the
>>>>> mutex just fine. you cant assume that zeroing the structure is the same
>>>>> as initializing the mutex.  that is why we have these initializer
>>>>> functions in the first place. are you suggesting that the
>>>>> __pthread_mutex_init() function is not doing its job ?
>>>>>           
>>>> yes exactly... but only if statically linked. I suspect that in this
>>>> case the __pthread_mutex_init is a nop...
>>>> likely due to weak aliasing... however, glibc does exactly the same call
>>>> to memset
>>>> and it uses
>>>>
>>>> #ifndef NOT_IN_libc
>>>>  __libc_lock_init (dirp->lock);
>>>> #endif
>>>>
>>>> instead of  __pthread_mutex_init(&(ptr->dd_lock), NULL);
>>>>         
>>> can you provide a test case ?  i'd like to fix the real problem ...
>>> adding a memset() just ignores the larger issue with every function that
>>> does something similar.
>>>       
>> below there is the test used by an our customer that reported the error.
>> You can simplify it as you like.
>>     
>
> unfortunately, it isnt hanging for me.  but i'm testing Blackfin here.  if i 
> checkout uClibc trunk at the rev just before your commit and build it for 
> sh4, that should be able to reproduce the issue, right ?  (i have sh4 
> hardware i can test on).
>   
It should, even if the problem appeared on nptl port, but, from this 
point of view, you know, the code is
the same. Anyway I have now a uclibc-linuxthreads for my sh4 target, I 
can check it.
>   
>> Anyway, regarding this issue, I was thinking in the past to review the
>> use of pthread dor locking
>> within the libc and use instead something like glibc (libc_lock)... any
>> comments about this ?
>>     
>
> i'm not terribly familiar with how glibc does internal locking, but i dont see 
> how it'd be any different from the locking we already have with 
> uClibc_mutex.h.  could you elaborate ?
> -mike
>   
I need to review this... it is something I was looking at times ago. 
Give me some time.
Carmelo