From owner-freebsd-arch Wed Jul 11 5:11:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 2C73937B405 for ; Wed, 11 Jul 2001 05:11:51 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id IAA20730; Wed, 11 Jul 2001 08:11:08 -0400 (EDT) Date: Wed, 11 Jul 2001 08:11:08 -0400 (EDT) From: Daniel Eischen To: Jason Evans Cc: Julian Elischer , arch@FreeBSD.ORG Subject: Re: help needed in threads.. (Signals) In-Reply-To: <20010710212453.E22464@canonware.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 10 Jul 2001, Jason Evans wrote: > On Tue, Jul 10, 2001 at 08:29:46PM -0700, Julian Elischer wrote: > > > 2/ are there separate handlers registerable per thread? (i.e. if thread A gets > > a SIGHUP call hangup() but if thread B gets a SIGHUP, call reload()) > > Yes, there are separare handlers per thread. However, I think this is > strictly a concern of the UTS, isn't it? I don't think this is true, at least that's not the way it currently is implemented in libc_r. But even if there were to be separate handlers per thread, I agree that it can be handled by the UTS. > > 3/ Is it possible that each thread has a mask but that the handlers are > shared? > > That would be evil programming practice, but AFAIK, nothing should prevent > a program from doing that. Actually, this is the way it works now. The only evil thing is trying to get more than 1 thread to handle the same signal. > > Certainly If you are nominating a thread to take each kind of interrupt > > then it makes no sense to have per-thread values for these. > > Proper programming practice says that at most one thread should have a > particular signal unmasked. Furthermore, it is generally best to use > sigwait(3). Yes! > > What semantics are we looking for? > > POSIX. If you don't already have a copy of Butenhof's "Programming with > POSIX Threads", get a copy; it's a wonderful book. You can also get a copy of the draft Austin (new POSIX) spec by registering as a reviewer (www.opengroup.org). There are more requirements that affect threads in there :( -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message