svn commit: r213241 - in head: include lib/libthr/thread

[David Xu]

Jung-uk Kim wrote:
> On Tuesday 28 September 2010 12:20 pm, Jung-uk Kim wrote:
>> On Tuesday 28 September 2010 12:02 pm, Jung-uk Kim wrote:
>>> On Tuesday 28 September 2010 09:31 am, John Baldwin wrote:
>>>> On Tuesday, September 28, 2010 12:57:56 am David Xu wrote:
>>>>> Author: davidxu
>>>>> Date: Tue Sep 28 04:57:56 2010
>>>>> New Revision: 213241
>>>>> URL: http://svn.freebsd.org/changeset/base/213241
>>>>>
>>>>> Log:
>>>>>   In current code, statically initialized and destroyed
>>>>> object have same null value, the code can not distinguish
>>>>> between them, to fix the problem, now a destroyed object is
>>>>> assigned to a non-null value, and it will be rejected by some
>>>>> pthread functions. PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP is
>>>>> changed to number 1, so that adaptive mutex can be statically
>>>>> initialized correctly.
>>>> Does this fix PR threads/150889 then?
>>> It seems it does.
>> Unfortunately, it seems to have a regression:
>>
>> %cat test.c
>> #include <pthread.h>
>> #include <stdio.h>
>>
>> static pthread_cond_t	static_cond = PTHREAD_COND_INITIALIZER;
>> static pthread_mutex_t	static_mutex = PTHREAD_MUTEX_INITIALIZER;
>>
>> int
>> main(void)
>> {
>>
>> 	// pthread_mutex_lock(&static_mutex);
>> 	printf("%d\n", pthread_cond_wait(&static_cond, &static_mutex));
>> 	pthread_mutex_unlock(&static_mutex);
>>
>> 	return (0);
>> }
>> %cc -o test test.c -pthread
>> %./test
>> Segmentation fault (core dumped)
>>
>> pthread_cond_wait(3) had to return EPERM here. :-(
> 
> I realized it is a libthr "feature" to catch real application bugs and 
> to increase performance by not checking rare conditions, I guess. :-/
> 
> Sorry for the noise,
> 
> Jung-uk Kim
> 
I think your example is legal, I might add checking back, however, it
would return two codes, EINVAL and EPERM.