Received: from SOUTH-STATION-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA08032; Wed, 13 Mar 96 13:56:55 EST
Received: from lennon.CS.Arizona.EDU by MIT.EDU with SMTP
	id AA15796; Wed, 13 Mar 96 13:53:31 EST
Received: (from mjk@localhost) by lennon.cs.arizona.edu (8.6.12/8.6.9) id LAA06534; Wed, 13 Mar 1996 11:53:52 -0700
Date: Wed, 13 Mar 1996 11:53:52 -0700
Message-Id: <199603131853.LAA06534@lennon.cs.arizona.edu>
From: "Mason J. Katz" <mjk@cs.arizona.edu>
To: pthreads@MIT.EDU
In-Reply-To: <199603131731.LAA22878@cascade.cs.utexas.edu>
	(grib@cs.utexas.edu)
Subject: Re: What's going on with MIT pthreads?

>>>>> "William" == "William S Gribble" <grib@cs.utexas.edu> writes:

    William> The remaining problems I have with the 4_1 release I
    William> haven't been able to precisely pin down, but they're
    William> related to signals.  There are conditions where signals
    William> just get dropped on the floor.. it happens semi-reliably
    William> when all threads are blocked on I/O or sleeping.  Have
    William> other people had this problem?

I've been able to solve all problems with signals by masking off all
signals using sigprocmask() and then dedicating one or more threads to
sigwait() for any interested signals.  sigwait() is quite nice as it
catches signals even when they are masked from the process and you
don't have to worry about asych handlers.

Does anyone know if sigwait() will catch multiple pending signals of
the same type?  Last I looked at the source I saw sigwait() clearing a
bit telling the thread-kernel the signal was pending.  Hence signals
could be lost...

-- 
Mason J. Katz					mjk@cs.arizona.edu
Systems Programmer
University of Arizona
