From owner-freebsd-arch Thu Mar 7 14: 0:46 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 93D8137B420 for ; Thu, 7 Mar 2002 14:00:14 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020307220014.WMOT1214.rwcrmhc54.attbi.com@InterJet.elischer.org> for ; Thu, 7 Mar 2002 22:00:14 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA44126 for ; Thu, 7 Mar 2002 13:44:09 -0800 (PST) Date: Thu, 7 Mar 2002 13:44:08 -0800 (PST) From: Julian Elischer To: arch@freebsd.org Subject: Contemplating THIS change to signals. (fwd) 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 Previously sent to -current.. received one +ve response I want a bit more comment before I spend time doing this work.. Does ANYONE have any comments.. If I do this am I going to get Matt'd? (ambushed). There is some behaviour in signals which seems 1/ un-neccesary 2/ potentially dangerous. in addition it is 3/ Definitly incompatible with KSEs. I am hoping that someone can give me a good reason why it is done, and failing that, I'm hoping people can give comments on my thoughts. The behavious in question was inherrited from BSD4.4-LITE2 When the sleep code (tsleep,msleep, cv{stuff}) checks to see if there is a pending signal that might cause the sleep to abort, it calls CURSIG() which calls issignal, which in turn might decide to actually suspend the process. (if the user hit ^Z for example) This is fine when CURSIG is called from userret(), because we are on the user boundary, however calling it from the sleep() call seems a rather UN-NICE thing to do. One could argue that it is safe because you are not allowed to sleep while holding resources (um is it not possible to sleep while holding a vnode?) but it seems that it is possible to hit ^Z at teh right moment while something is holding some resource (during what it expects to be a very short term sleep,) and end up blocking the whole system. I would argue that a process can be considered to be suspended even while it is running in kernel space. My definition of a suspended process would be one that id not running any user code. it is not making any headway on the userland program. This I put it to the group that it is sufficient to only suspend a process when it is crossing the user boundary. (returning to user space) My suggestion is to remove teh code in issignal() that perfoms the blocking actions and create a separate function that does that action. I would then call that function from userret() immediatly after the call to issignal(). The result would be that suspended processes would still not reach userland, but processes would not have to option of suspending indefinitly at sleep(). The signal would still cut short the sleep, but the process would be allowed to proceed to the user boundary, at which point it would be suspended as before. If anyone has any reasons they think this is a bad idea, then please speak up. Neithe Matt (Dillon) nor I can see that stopping in msleep is required, and both of us are in fact un-easy with it. In a THREADED world it gets even more complicated, because the SUSPENDED state is a PER_PROCESS state, which means that you are not suspented until ALL THERADS have left userland and been counted as 'suspended'. Having some threads stopped 'near' msleep and others stopped at the userland boundary is asking for trouble in my opinion. I can not think of any downside to making the suspension (whether from ptrace, or a signal) only occur at the user boundary. If I hear NO arguments I'll take it that no-one can think of any reasons to not change the code. If yuo have a reason PLEASE speak up so that we can discuss it and try figure out whether it is real or can be gotten around in some manner. Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message