Date: Wed, 3 Nov 2004 10:24:10 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: Mike Makonnen <mtm@identd.net> Cc: John Baldwin <jhb@freebsd.org> Subject: Re: More mono + libpthread breakage.. Message-ID: <Pine.GSO.4.43.0411031019050.9924-100000@sea.ntplx.net> In-Reply-To: <20041103141914.GA2095@rogue.acs.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0411031019050.9924-100000>