Date: Thu, 13 Sep 2001 03:28:27 +0200 From: Tor.Egge@fast.no To: jkf@research.bell-labs.com Cc: freebsd-questions@FreeBSD.ORG Subject: Re: Linux threads loses signal Message-ID: <200109130128.DAA16137@midten.fast.no> In-Reply-To: Your message of "Wed, 12 Sep 2001 16:43:52 -0400 (EDT)" References: <200109122043.QAA23910@zydeco.research.bell-labs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
> We have an application using the linuxthreads package, version 2.1.3_2,
> installed on FreeBSD 4.3. The application occassionally gets blocked
> waiting in pthread_cond_timedwait_relative_old(), at least from the
> stack trace. There are many threads, 13, in the application each calling
> pthread_cond_timedwait. We have been unable to recreate the problem
> in a smaller program, since we don't understand what is happening in
> the linuxthreads library with cond_timedwait.
The thread is probably restarted before it reduces the resume count in
__pthread_timedsuspend_old(), thus no signal is sent by
__pthread_restart_old().
> Does any one have ideas on what the problem might be and/or a fix?
Try the enclosed patch. It causes __pthread_timedsuspend_old() to
assume that a restart signal has already been delivered if the resume
count wasn't atomically reduced from 0 to -1 in the first if
statement.
- Tor Egge
[-- Attachment #2 --]
--- pthread.c.OLD Wed Sep 12 23:28:16 2001
+++ pthread.c Thu Sep 13 00:12:15 2001
@@ -947,7 +947,7 @@
__pthread_timedsuspend_old(pthread_descr self, const struct timespec *abstime)
{
sigset_t unblock, initial_mask;
- int was_signalled = 0;
+ int was_signalled = 1;
sigjmp_buf jmpbuf;
if (atomic_decrement(&self->p_resume_count) == 0) {
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200109130128.DAA16137>