Date: Thu, 31 Jan 2002 18:39:23 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: arch@freebsd.org Subject: KSE and SIGNALS (How to feel ill in 30 seconds) Message-ID: <Pine.BSF.4.21.0201311457400.63083-100000@InterJet.elischer.org>
next in thread | raw e-mail | index | archive | help
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. In other words whenever the next return to user space is made after the signal is posted, the signal will be acted upon. 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. * 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). * 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). * 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. * 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. * A separate signal stack is provided. Not an upcall, just dedicated. In addition to this is the complication that ptrace is bound up in signals as well. I'm slowely reworking ptrace so that you can specify a thread but first I have to break it away from using signals to pass it's state because signals are per-process and not per-thread.... 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.0201311457400.63083-100000>