Date: Wed, 11 Jul 2001 08:03:43 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Julian Elischer <julian@elischer.org> Cc: Jason Evans <jasone@canonware.com>, arch@FreeBSD.ORG Subject: Re: help needed in threads.. (Signals) Message-ID: <Pine.SUN.3.91.1010711073450.15505A-100000@pcnet1.pcnet.com> In-Reply-To: <3B4BC829.C3879AF2@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 10 Jul 2001, 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 is a per process signal mask, but it isn't directly accessable by the application since sigprocmask gets and sets the _thread_ signal mask. sigprocmask() is wrapped by the UTS which will call __sys_sigprocmask if necessary. Right now (libc_r), the threads library installs a signal handler for every signal that can be handled. The threads library also keeps track of any handlers that the application installs (sigaction is also wrapped by the threads library). If the action is SIG_DFL or SIG_IGN, the threads library will pass that to the kernel. This is really the only way that a threaded application (currently) can affect the process signal mask. > 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()) No, there is only one set of application handlers which the UTS keeps track of. The handler (there is only 1 handler for all signals) that actually gets installed into the process is the UTS signal handler. The UTS handler does some initial setup and calls the application handler. When the application handler returns, there may be some cleanup needed. > 3/ Is it possible that each thread has a mask but that the handlers are shared? Yes, this is how libc_r currently behaves. > (by mask I mean a block mask, and an IGN mask at least.) All you need is a block mask per thread. > 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? It still gets sent to the UTS. Yes, the UTS will have to block it for the whole process explicitly if it doesn't want to see it. BTW, we also have to worry about queueing signals eventually. > 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? Since there is only one set of installed handlers, the sa_flags are process wide. The application can set these when it calls sigaction, and the UTS will look at these flags and apply them to the process signal handler if necessary. libc_r currently doesn't allow the application to set the sa_flags in the kernels copy of sigacts, but that is because the threads library wraps blockable system calls and checks for EINTR. > 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. > > 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. Right. I think we only want per-process sigacts. > 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. > > What semantics are we looking for? Use the rules that I posted before. There can only ever be 1 thread that gets a signal. In the case of a thread waiting in sigwait(), no handler is even called. -- Dan Eischen 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?Pine.SUN.3.91.1010711073450.15505A-100000>