Date: Fri, 1 Feb 2002 08:56:13 -0500 (EST) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Julian Elischer <julian@elischer.org> Cc: arch@FreeBSD.ORG Subject: Re: KSE and SIGNALS (How to feel ill in 30 seconds) Message-ID: <Pine.GSO.4.10.10202010843200.6066-100000@pcnet1.pcnet.com> In-Reply-To: <Pine.BSF.4.21.0201312320470.64929-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 31 Jan 2002, Julian Elischer wrote: > On Fri, 1 Feb 2002, Daniel Eischen wrote: > > 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. OK > > 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.) Yep, I understand that the kernel knows where to store the current threads state, but I'm sure we agree that that's not enough info for the kernel to deliver signals to the correct thread. As far as debugging a multithreaded program, when I hit a breakpoint or something I would expect all threads to suspend. I should be able to switch between threads in the debugger and see where each one was. > > > > 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? You can send them all at once in the same upcall if you want. For now, why don't you use the process' signal mask (in the same way as is currently done) to decide which signals can be sent. I can't really forsee why we would need to block any signals (since the UTS will know whether they are blocked and can make them pending if necessary). -- 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.GSO.4.10.10202010843200.6066-100000>