Date: Wed, 3 Nov 2004 18:54:42 +0300 From: Mike Makonnen <mtm@identd.net> To: Daniel Eischen <deischen@freebsd.org> Cc: John Baldwin <jhb@freebsd.org> Subject: Re: More mono + libpthread breakage.. Message-ID: <20041103155441.GA1601@rogue.acs.lan> In-Reply-To: <Pine.GSO.4.43.0411031019050.9924-100000@sea.ntplx.net> References: <20041103141914.GA2095@rogue.acs.lan> <Pine.GSO.4.43.0411031019050.9924-100000@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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@identd.net | Fingerprint: AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon !
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041103155441.GA1601>