From the net: -=-=-=-=- The pthread_once() implementation seems have different semantics with the one in POSIX standard pthread. (The reference is in page 118 in O'Reilly's book"Pthreads programming" 1st ed. I assume that the book is correct on this.) This is the text describing pthread_once() semantics on the book: "No caller will exit from pthread_once mechanism until the routine's first caller has returned." -=-=-=-=- which is true. The poster suggested: -=-=-=-=- In a word, I think there should be a pair of mutex lock/unlocks around the invocation of the function pointer passed by user in pthread_once() in compat/posix/current/src/pthread.cxx to guarantee the correct semantics. -=-=-=-=- My reply includes: -=-=-=-=- That wouldn't be ideal as _all_ pthread_once's would be serialized. This would be fatal if the called routine itself called pthread_once. Also we have to worry about the thread being cancelled in the called routine. Instead, at a guess, the thing to do is to use the pthread_once_t to record whether the routine is currently still being processed, and then broadcast a condition variable to cause it to be checked by any waiting routines that have called it. -=-=-=-=-
This bug has moved to http://bugs.ecos.sourceware.org/show_bug.cgi?id=50036