Date: Thu, 31 Jan 2002 23:35:33 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: arch@FreeBSD.ORG Subject: Re: KSE and SIGNALS (How to feel ill in 30 seconds) Message-ID: <Pine.BSF.4.21.0201312320470.64929-100000@InterJet.elischer.org> In-Reply-To: <Pine.GSO.4.10.10202010001020.6333-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 1 Feb 2002, Daniel Eischen wrote: > On Thu, 31 Jan 2002, Julian Elischer wrote: > > Well, we have no real design yet for handling signals in > > a multi-threaded process. > > In the current statem the signals would be handled by whatever > > thread is next returned to by the system, or > > in fact if it is an upcall, it would be handled on the UTS stack if that > > was next. (In the current incarnation, all syscalls return with an upcall > > so quite a few signals would be handled on the UTS stack. > > Only syscalls that block should return via an upcall. Or am > I misunderstanding something. For instance, getpid() should > not result in an upcall. You'd add the cost of a context > switch (even if is a userland switch) for every system call. > And it's not just a context switch. An upcall event would > probably force a check of the scheduling queue, locks would > have to be taken, etc. That is the aim, but to get things up and running fast I'm upcalling on all syscall returns. Not doing so is an optimisation we can add... but it cloudes some of the issues I want to test. > > Just make signals an upcall notification. The same thing has > to happen in trying to deliver a signal as when a thread blocks > in the kernel. The UTS gets notified of the event(s), handles > the event(s), and chooses another thread to run. When a signal > arrives, the UTS has to find a thread to handle it and schedule > the thread to run. Once it finds a thread to handle the signal, > it just elevates the threads priority, inserts it into the > run queue, and chooses a new thread. Most likely, the same > thread will be pulled from the run queue. > > > In other words whenever the next return to user space is > > made after the signal is posted, the signal will be acted upon. > > That's fine as long as it is an upcall. > > > It is likely that we want to do something a little more > > consitent than this. > > > > Some possibilities: > > > > * Leave it as it is.. The signals are done on whatever thread is > > next, even if it is an upcall. > > Yes, we handle this now, but it isn't too pretty. > > > * A special upcall location is assigned for them. The upcall is > > scheduled instead of whatever the next return to userland > > would be (which is delayed). > > Whether it is a special upcall or not, I don't think it matters. > But an upcall would be preferred, and we shouldn't get another > upcall while we are currently in one (whether it is a signal > upcall or the other kind(s)). > > > * They are returned only on upcalls (choosing the next one up) > > (upcalls can be done at almost any time that there is not already > > an upcall in progress). > > This is good. > > > * They are returned only on a particular upcall stack (but it > > may not be active for a while, maybe we can force it to happen. > > POSIX says that signals should be delivered as soon as possible. > That leaves a lot of room, but there is no reason why a signal > event should be any different than any other event that generates > an upcall. > > > * They are returned only on a specified user thread, (but there > > is nothing to say that the UTS will schedule that thread any time > > soon. > > If the UTS wants to dedicate a special thread for signal delivery, > that is its own business. From the kernels point of view, and > since the kernel doesn't know anything about user threads, just > notify the UTS of the signal event, and let the UTS deal with it > the way it wants to. The kernel DOES know SOMETHING about user threads.. It knows the address it should return state at on each syscall, should it block, and thus can "know" when a particular thread is running by assuming that whenever that address is given, that thread is working. it is really just a number, but the changes to ptrace will use that number to associate a thread with wether or not it should be single stepped or not. (it's a long story, bu you need soem way to know if the 'single step' but should be set for a returning thread or not. In thread mode, only a returning thread that is associated with a particular mailbox will be single stepping.) > > > * A separate signal stack is provided. Not an upcall, just dedicated. > > This isn't any different than the current system when sigaltstack > is used. Each upcall has it's own stack, so I don't see this > being useful. ok.. > > I've probably mentioned this a couple of times, but it may help > you to know how signals should happen in a threaded application. > There's no way the kernel can deliver the signal to the correct > thread; only the UTS knows the state of all the threads, their > masks, etc. When a signal is delivered to a thread, it really > has to happen in the context of that thread. It can't easily > be on any other stack than the threads own stack. So when the > UTS sets up a thread to handle a signal, it's similar to the > way the kernel delivers a signal (the old way). It adds a frame > to the top of the threads stack that knows how to invoke the > handler and return back to the threads interrupted context. > Since the UTS has to fiddle with a threads stack to install a > signal handler on it, it is easier if the signal notification > to the UTS does _not_ happen on the stack of any thread; > otherwise we have to make special exceptions for handling > signals on the current thread. Ok that makes it easy (approximatly) for me :-) > > My preference is to have signals be upcall notifications of > some sort. I don't see why they can't use the same upcall > as other kernel events. ok. what if there are multiple signals? do you want agregation? > > -- > 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.BSF.4.21.0201312320470.64929-100000>