More mono + libpthread breakage..

[Daniel Eischen]

On Wed, 3 Nov 2004, Mike Makonnen wrote:

> On Tue, Nov 02, 2004 at 05:12:11PM -0500, John Baldwin wrote:
> > This kicks in with mono because mono wants to call
> > 'sem_post()' (which is supposed to be signal safe) from a signal handler, but
> > sem_post() calls pthread_mutex_lock() which dies with an assertion error
> > about already being on a syncq since _cond_wait_backout() didn't happen.
>
> Then the correct fix is for sem_post to disable signals around calls to
> pthread functions. There are *no* async-signal safe pthread functions.

No, the problem has already occurred when sem_post() is called.  A signal
occurs while blocked in pthread_cond_wait() but there is a race where the
thread doesn't get removed from the CV queue then calls sem_post() which
tries to requeue the thread on another synchronization queue.  Normally
when a signal interrupts a pthread_cond_wait(), the thread should get
removed from the CV queue before calling the signal handler but this
isn't happening.

I am curious to see whether the fix I suggested solves the problem.

-- 
Dan Eischen