From owner-freebsd-arch Tue Jul 10 21:24:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from canonware.com (dsl081-058-209.dsl-isp.net [64.81.58.209]) by hub.freebsd.org (Postfix) with ESMTP id A3EE837B401 for ; Tue, 10 Jul 2001 21:24:39 -0700 (PDT) (envelope-from jasone@canonware.com) Received: by canonware.com (Postfix, from userid 1001) id 242A1C9; Tue, 10 Jul 2001 21:24:54 -0700 (PDT) Date: Tue, 10 Jul 2001 21:24:53 -0700 From: Jason Evans To: Julian Elischer Cc: Daniel Eischen , arch@FreeBSD.ORG Subject: Re: help needed in threads.. (Signals) Message-ID: <20010710212453.E22464@canonware.com> References: <3B4BC829.C3879AF2@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B4BC829.C3879AF2@elischer.org>; from julian@elischer.org on Tue, Jul 10, 2001 at 08:29:46PM -0700 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, Jul 10, 2001 at 08:29:46PM -0700, Julian Elischer wrote: > Daniel Eischen wrote: > > > Ok so I think I have it 'kinda' worked out in my head.. > there are some loose ends however that depend on how the interrupt masks etc are > handled... > > In KSE mode: > 1/ is there still a "per process" signal mask, and set of handler > addresses? Or just separate ones per thread? There still can be (and probably should be) a per-process signal mask. IIRC, under normal circumstances, a threaded program shouldn't use it, but doing so isn't strictly forbidden. > 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? > 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. > (by mask I mean a block mask, and an IGN mask at least.) > > If all threads block an interrupt, does the process then block it? > (or does it still get to the UTS? Does the UTS have to block it fo the > whole process explicitly if it doesn't want to see it I think we could go either way on this. It may make sense for the UTS to block it for the whole process for efficiency reasons (but I can't think of an example where it would be important to do so). > If a thread is designated to take an interrupt and it is blocked in > the kernel, then the same rules apply as for a current process. > however is the fact that a syscall is restartable, a process wide > setting or a thread-specific setting? > > To make sense I think the flags SA_NOCLDSTOP, SA_NOCLDWAIT are definitly > per process. The SA_RESTART could have arguments each way, and similarly > SA_ONSTACK ans SA_NODEFER and SA_RESETHAND might also be per thread. I don't know for sure off the top of my head, but I think it is a process wide setting. > 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). > but if the threads declare their own interest, then they could > have their own masks etc. In that case it makes sense to deliver the > signal to ALL threads that express an interest in a particular signal. > > (I could imagine for example that two threads may want to know about the > SIGHUP that indicates a restart of a daemon). > Similarly a SIGTSTP should be sent to all threads in the default case > because you want the entire program to suspend, Similarly you want SIGCONT > to continue all threads. POSIX says that only one thread gets the signal. I recently went through great pain to make a threaded program work with SIGTSTP and SIGCONT, but that's the way things are supposed to work, so we need to do it that way. > 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. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message