More mono + libpthread breakage..

[Mike Makonnen]

On Wed, Nov 03, 2004 at 10:24:10AM -0500, Daniel Eischen wrote:
> On Wed, 3 Nov 2004, Mike Makonnen wrote:
> 
> 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.

Ok, I misread the problem. However, even if my proposed solution doesn't help,
the heart of the problem is that while sem_post is signal-safe, none of the
pthreads API is safe. So you can call sem_post from within a signal handler,
but sem_post cannot expect to safely call a pthreads function from within
the signal handler; therefore, it has to find some other means of
synchronization.

While it is ok for a pthreads implementation to try to be more robust in
these kinds of situations it certainly isn't required by the standard. So
sem_post is relying on behaviour that is explicitly *not* guaranteed by
POSIX (hence it is in-breach of its signal-safe status).

I may be wrong, and welcome any corrections to my interpretation of
the situation.

Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
mtm at identd.net | Fingerprint: AC7B 5672 2D11 F4D0 EBF8  5279 5359 2B82 7CD4 1F55
mtm at FreeBSD.Org| FreeBSD - Unleash the Daemon !