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 _______________________________________________ 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"