Date: Thu, 7 Mar 2002 13:44:08 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: arch@freebsd.org Subject: Contemplating THIS change to signals. (fwd) Message-ID: <Pine.BSF.4.21.0203071342160.37321-100000@InterJet.elischer.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0203071342160.37321-100000>