Date: Tue, 10 Jul 2001 21:53:05 -0700 From: Julian Elischer <julian@elischer.org> To: Daniel Eischen <eischen@vigrid.com>, Jason Evans <jasone@canonware.com>, arch@FreeBSD.ORG Subject: Re: help needed in threads.. (Signals) Message-ID: <3B4BDBB1.AF248E58@elischer.org> References: <Pine.SUN.3.91.1010710080954.5316A@pcnet1.pcnet.com> <3B4BC829.C3879AF2@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote:
>
> Daniel Eischen wrote:
> >
> Ok so I think I have it 'kinda' worked out in my head..
> there are some loose ends however that depend on how the interrupt masks etc are
> handled...
>
> In KSE mode:
> 1/ is there still a "per process" signal mask, and set of handler
> addresses? Or just separate ones per thread?
>
> 2/ are there separate handlers registerable per thread? (i.e. if thread A gets
> a SIGHUP call hangup() but if thread B gets a SIGHUP, call reload())
>
> 3/ Is it possible that each thread has a mask but that the handlers are shared?
>
> (by mask I mean a block mask, and an IGN mask at least.)
>
> If all threads block an interrupt, does the process then block it?
> (or does it still get to the UTS? Does the UTS have to block it fo the
> whole process explicitly if it doesn't want to see it?
>
> If a thread is designated to take an interrupt and it is blocked in
> the kernel, then the same rules apply as for a current process.
> however is the fact that a syscall is restartable, a process wide
> setting or a thread-specific setting?
>
> To make sense I think the flags SA_NOCLDSTOP, SA_NOCLDWAIT are definitly
> per process. The SA_RESTART could have arguments each way, and similarly
> SA_ONSTACK ans SA_NODEFER and SA_RESETHAND might also be per thread.
>
> Certainly If you are nominating a thread to take each kind of interrupt
> then it makes no sense to have per-thread values for these.
>
> but if the threads declare their own interest, then they could
> have their own masks etc. In that case it makes sense to deliver the
> signal to ALL threads that express an interest in a particular signal.
>
> (I could imagine for example that two threads may want to know about the
> SIGHUP that indicates a restart of a daemon).
> Similarly a SIGTSTP should be sent to all threads in the default case
> because you want the entire program to suspend, Similarly you want SIGCONT
> to continue all threads.
>
> What semantics are we looking for?
to continue my own thoughts:
The reasoning for interrupting syscalls is so that a program can decide to
abort or do other syscalls, because there is no sureness that the syscall
doesnt hold resources. In our case if we run the signal handler in a separate
kernel thread (an upcall) we really don't care what the other syscalls are doing
in fact if we didcare it would be a bug.
( If it comes to the user boundary before doing the signal then
it has cleaned everything up and cannot be holding resources.)
The only reason that a user would want a signal sent to a particular thread
in this case would be toachieve what was originally the side effect of
interrupting
the syscall. The handler could be run from any thread's stack as long as it
could do it's work. I think therefore that one way to do what we want would be
to
simply do the handler directly from the upcall, and then interrupt
the appropriate thread if it happens to be in the kernel. In other words
we explicitly create the side-effect if asked to do so.
I guess that the restartabiliy is so that arbitrary unaltered programs
can be stopped with SIGSTOP and restarted with SIGCONT, without
needing to handle these situations. A restartable syscall in threads is easy....
don't interrupt it in the first place!. If the thread decides to do something
that
causes teh program to exit, then that syscall will have to be cleaned up in
exactly the same manner as all the others.
(which brings up the case of what to do if one thread is in an UNINTERRUPTABLE
syscall when another does an exit().)
In non threaded mode, if a signal handler is invoked during a SA_RESTART able
syscall, is there any way it can abort that syscall and stop it from
restarting?
(I gotta go read code).
>
> Julian.
>
> --
> +------------------------------------+ ______ _ __
> | __--_|\ Julian Elischer | \ U \/ / hard at work in
> | / \ julian@elischer.org +------>x USA \ a very strange
> | ( OZ ) \___ ___ | country !
> +- X_.---._/ presently in San Francisco \_/ \\
> v
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-arch" in the body of the message
--
+------------------------------------+ ______ _ __
| __--_|\ Julian Elischer | \ U \/ / hard at work in
| / \ julian@elischer.org +------>x USA \ a very strange
| ( OZ ) \___ ___ | country !
+- X_.---._/ presently in San Francisco \_/ \\
v
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?3B4BDBB1.AF248E58>