From owner-freebsd-arch Thu Mar 7 18:34:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 2ADFF37B402 for ; Thu, 7 Mar 2002 18:34:36 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id g282YPD38378; Thu, 7 Mar 2002 21:34:25 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 7 Mar 2002 21:34:25 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Julian Elischer Cc: arch@freebsd.org Subject: Re: Contemplating THIS change to signals. (fwd) 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, 7 Mar 2002, Julian Elischer wrote: > 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) Eww. That sounds bad for all the reasons you identify. > 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. That sounds like a reasonable argument to me. > 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) Sounds good. Asserting that the STOP state only affects a process when executing in userland makes sense to me. Question: how will this impact shells that suspend a child process--do they generally restore control to the user immediately, or wait for it to "succeed" somehow? Will it now be the case that hitting Ctrl-Z for an application using sendfile() will not take affect until the file is sent? > 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(). Sounds good. A recipe for deadlock, otherwise. > 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. Sounds right. One of the nice things about KSE is that it allows us to not have to deal with many threading issues, leaving that to the userland thread library. For example, we can assert that a process go down to one kernel thread of execution with no parallelism before calling fork() or exec(), and leave it up to the userland library how it gets there if it wants to do it cleanly. > I can not think of any downside to making the suspension (whether from > ptrace, or a signal) only occur at the user boundary. The only question I have is the one mentioned above -- what weird impacts, if any, this would have on expected shell behavior. > 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. Generally sounds good. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message