Date: Thu, 7 Mar 2002 21:34:25 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: Julian Elischer <julian@elischer.org> Cc: arch@freebsd.org Subject: Re: Contemplating THIS change to signals. (fwd) Message-ID: <Pine.NEB.3.96L.1020307212843.32978H-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.21.0203071342160.37321-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020307212843.32978H-100000>