Date: Tue, 10 Jul 2001 21:24:53 -0700 From: Jason Evans <jasone@canonware.com> To: Julian Elischer <julian@elischer.org> Cc: Daniel Eischen <eischen@vigrid.com>, arch@FreeBSD.ORG Subject: Re: help needed in threads.. (Signals) Message-ID: <20010710212453.E22464@canonware.com> In-Reply-To: <3B4BC829.C3879AF2@elischer.org>; from julian@elischer.org on Tue, Jul 10, 2001 at 08:29:46PM -0700 References: <Pine.SUN.3.91.1010710080954.5316A@pcnet1.pcnet.com> <3B4BC829.C3879AF2@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010710212453.E22464>