On Wed, 29 Sep 2010, David Xu wrote:

Jung-uk Kim wrote:
On Tuesday 28 September 2010 12:20 pm, Jung-uk Kim wrote:
[ snip ]
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.

By default, I think we should check.  I think PTHREAD_MUTEX_DEFAULT
should be equal to PTHREAD_MUTEX_ERRORCHECK.  So
PTHREAD_MUTEX_INITIALIZER would default to error checking.

I also agree -- if the mutex isn't valid, then return EINVAL,
and if not locked, return EPERM.

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

Reply via email to