From owner-freebsd-arch Thu Jan 31 21:34:57 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 50FB937B404 for ; Thu, 31 Jan 2002 21:34:45 -0800 (PST) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.1/8.12.1) with ESMTP id g115Yih3010394; Fri, 1 Feb 2002 00:34:44 -0500 (EST) Date: Fri, 1 Feb 2002 00:34:44 -0500 (EST) From: Daniel Eischen To: Julian Elischer Cc: arch@FreeBSD.ORG Subject: Re: KSE and SIGNALS (How to feel ill in 30 seconds) In-Reply-To: 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 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. 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 retunred 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. > * 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. 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. 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. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message