Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 1 Feb 2002 00:34:44 -0500 (EST)
From:      Daniel Eischen <eischen@pcnet1.pcnet.com>
To:        Julian Elischer <julian@elischer.org>
Cc:        arch@FreeBSD.ORG
Subject:   Re: KSE and SIGNALS (How to feel ill in 30 seconds)
Message-ID:  <Pine.GSO.4.10.10202010001020.6333-100000@pcnet1.pcnet.com>
In-Reply-To: <Pine.BSF.4.21.0201311457400.63083-100000@InterJet.elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 31 Jan 2002, Julian Elischer wrote:
> 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.

Only syscalls that block should return via an upcall.  Or am
I misunderstanding something.  For instance, getpid() should
not result in an upcall.  You'd add the cost of a context   
switch (even if is a userland switch) for every system call.
And it's not just a context switch.  An upcall event would
probably force a check of the scheduling queue, locks would
have to be taken, etc.

Just make signals an upcall notification.  The same thing has
to happen in trying to deliver a signal as when a thread blocks
in the kernel.  The UTS gets notified of the event(s), handles
the event(s), and chooses another thread to run.  When a signal
arrives, the UTS has to find a thread to handle it and schedule
the thread to run.  Once it finds a thread to handle the signal,
it just elevates the threads priority, inserts it into the
run queue, and chooses a new thread.  Most likely, the same
thread will be pulled from the run queue.

> In other words whenever the next return to user space is 
> made after the signal is posted, the signal will be acted upon.

That's fine as long as it is an upcall.

> 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.

Yes, we handle this now, but it isn't too pretty.

> * 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).

Whether it is a special upcall or not, I don't think it matters.
But an upcall would be preferred, and we shouldn't get another
upcall while we are currently in one (whether it is a signal
upcall or the other kind(s)).

> * 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).

This is good.

> * 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.

POSIX says that signals should be delivered as soon as possible.
That leaves a lot of room, but there is no reason why a signal
event should be any different than any other event that generates
an upcall.

> * 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.

If the UTS wants to dedicate a special thread for signal delivery,
that is its own business.  From the kernels point of view, and
since the kernel doesn't know anything about user threads, just
notify the UTS of the signal event, and let the UTS deal with it
the way it wants to.

> * A separate signal stack is provided. Not an upcall, just dedicated.

This isn't any different than the current system when sigaltstack
is used.  Each upcall has it's own stack, so I don't see this
being useful.

I've probably mentioned this a couple of times, but it may help
you to know how signals should happen in a threaded application.
There's no way the kernel can deliver the signal to the correct
thread; only the UTS knows the state of all the threads, their
masks, etc.  When a signal is delivered to a thread, it really
has to happen in the context of that thread.  It can't easily
be on any other stack than the threads own stack.  So when the
UTS sets up a thread to handle a signal, it's similar to the
way the kernel delivers a signal (the old way).  It adds a frame
to the top of the threads stack that knows how to invoke the
handler and return back to the threads interrupted context.
Since the UTS has to fiddle with a threads stack to install a
signal handler on it, it is easier if the signal notification
to the UTS does _not_ happen on the stack of any thread;
otherwise we have to make special exceptions for handling
signals on the current thread.

My preference is to have signals be upcall notifications of
some sort.  I don't see why they can't use the same upcall
as other kernel events.

-- 
Dan Eischen


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.GSO.4.10.10202010001020.6333-100000>