> > > > says...
> > > > It is a thread, known as Kernel Trap Handler. How to find it I assume
> > > Unless I'm very mistaken the kernel trap handler only gets involved when
> > > userland processes cause a trap, e.g by accessing unmapped memory
> > > etc. For many signals, e.g SIGCHLD they are sent by the kernel straight
> > > the process in question.
> > Nope. Always thru Kernel Trap Handler. I've checked Solaris Internals
> > book.
> Having looked at the Solaris Internals book and had a quick glance at the
> Solaris 8 Foundation Source code I'm still convinced this isn't the case. To
> quote from the book:
> "Signals generated as a direct result of an error encountered during
> instruction execution start with a hardware trap on the system.... The
> kernel-installed trap handler ultimately generates a signal to the thread
> that caused the trap"
> So hardware traps (like segmentation faults etc) do indeed hit the kernel
> trap handler, but they are the only things that hit the handler. I just
> can't see how you extend that to other signals. The original question was in
> regards to signals generated through TTY input, they definitely don't hit
> the trap handler. In fact, they hit the TTY streams module and are converted
> to M_PCSIG streams messages, which I think are later delivered by the kernel
> at the point when the message it taken from the stream head (i.e there is no
> intervening thread).
Hi Shaun !
Of course is possible, that real work may differ from the Solaris
Internals book, but I still have a trust to it.
So look on the page 332 which says:
"Regardless of the source of the signal, the ultimate delivery mechanism
through the operating system is the kernel sigtoproc() function, which
takes up to four arguments: a process pointer, a kernel thread pointer,
the signal number, and the optional flag, fromuser, which indicates
whether the source of the signal was the kernel or user. A NULL kthread
pointer indicates the signal should be posted to the process."
and a few later
"A lot of the upfront work in sigtoproc() deals with job control and the
terminal I/O signals. In compliance with the POSIX specifications, this
behavior is documented in the signal(5) manual page"
As I mentioned, this is cut&paste from the book.
If you can come up with some other facts, I would like to hear it to
change my oppinion (and knowledge :) .