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.
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
