which kernel process is actually responsible for receiving the Signals

which kernel process is actually responsible for receiving the Signals

Post by Ravi Verm » Sat, 01 Mar 2003 10:09:20



Hi,
I have a very precise question for which I'm looking for an answer. which
kernel process is actually responsible for  receiving the Signals and then
forwarding to my process. While I do know what are signals and how to write
the handlers, what specifically I need is which process receives first the
Signal that I send through the tty and then it forwards it to my process.

thanks in advance
Ravi Verma

 
 
 

which kernel process is actually responsible for receiving the Signals

Post by p.. » Sat, 01 Mar 2003 17:43:45



> Hi,
> I have a very precise question for which I'm looking for an answer. which
> kernel process is actually responsible for  receiving the Signals and then
> forwarding to my process. While I do know what are signals and how to write
> the handlers, what specifically I need is which process receives first the
> Signal that I send through the tty and then it forwards it to my process.
> thanks in advance
> Ravi Verma

It's no process in the usual sense, it's the kernel.

About the only thing you could interfere with these is by
kernel modification of some kind.

Why do you ask ?

--
Peter H?kanson        
        IPSec  Sverige      ( At Gothenburg Riverside )
           Sorry about my e-mail address, but i'm trying to keep spam out,
           remove "icke-reklam" if you feel for mailing me. Thanx.

 
 
 

which kernel process is actually responsible for receiving the Signals

Post by Casper H.S. Di » Sat, 01 Mar 2003 20:09:10



>Hi,
>I have a very precise question for which I'm looking for an answer. which
>kernel process is actually responsible for  receiving the Signals and then
>forwarding to my process. While I do know what are signals and how to write
>the handlers, what specifically I need is which process receives first the
>Signal that I send through the tty and then it forwards it to my process.

Signals don't really exist inside the kernel; an event will happen
(system call, faulting instruction, etc) which will then be mapped by
the kernel to a signal for a specific (group of) process(es).

I.e., the first process that sees signals as signals is the process
that receives them.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 
 
 

which kernel process is actually responsible for receiving the Signals

Post by Music Ma » Sat, 01 Mar 2003 22:23:46



says...
Quote:> Hi,
> I have a very precise question for which I'm looking for an answer. which
> kernel process is actually responsible for  receiving the Signals and then
> forwarding to my process. While I do know what are signals and how to write
> the handlers, what specifically I need is which process receives first the
> Signal that I send through the tty and then it forwards it to my process.

> thanks in advance
> Ravi Verma

It is a thread, known as Kernel Trap Handler. How to find it I assume
will be difficult for you. It catches any signal sent to any process,
and then it checks if this process has changed the address of that trap
to take actions of their own. If so, it then follows the address set
within process signal. (see /usr/proc/bin/psig...)

Hope it helps.

 
 
 

which kernel process is actually responsible for receiving the Signals

Post by Music Ma » Sat, 01 Mar 2003 22:24:46





> >Hi,
> >I have a very precise question for which I'm looking for an answer. which
> >kernel process is actually responsible for  receiving the Signals and then
> >forwarding to my process. While I do know what are signals and how to write
> >the handlers, what specifically I need is which process receives first the
> >Signal that I send through the tty and then it forwards it to my process.

> Signals don't really exist inside the kernel; an event will happen
> (system call, faulting instruction, etc) which will then be mapped by
> the kernel to a signal for a specific (group of) process(es).

> I.e., the first process that sees signals as signals is the process
> that receives them.

Not true. Its the kernel first.

- Show quoted text -

Quote:

> Casper

 
 
 

which kernel process is actually responsible for receiving the Signals

Post by those who know me have no need of my nam » Mon, 03 Mar 2003 13:44:35


in comp.unix.internals i read:

Quote:>I have a very precise question for which I'm looking for an answer. which
>kernel process is actually responsible for  receiving the Signals and then
>forwarding to my process.

all the world is not a vax, much less ultrix.

--
bringing you boring signatures for 17 years

 
 
 

which kernel process is actually responsible for receiving the Signals

Post by Shaun Clowe » Wed, 05 Mar 2003 15:04:26




> says...
> It is a thread, known as Kernel Trap Handler. How to find it I assume
> will be difficult for you. It catches any signal sent to any process,
> and then it checks if this process has changed the address of that trap
> to take actions of their own. If so, it then follows the address set
> within process signal. (see /usr/proc/bin/psig...)

Unless I'm very mistaken the kernel trap handler only gets involved when
userland processes cause a trap, e.g by accessing unmapped memory (SIGSEGV)
etc. For many signals, e.g SIGCHLD they are sent by the kernel straight to
the process in question.

Cheers,
Shaun

 
 
 

which kernel process is actually responsible for receiving the Signals

Post by Music Ma » Tue, 18 Mar 2003 16:21:05







> > says...
> > It is a thread, known as Kernel Trap Handler. How to find it I assume
> > will be difficult for you. It catches any signal sent to any process,
> > and then it checks if this process has changed the address of that trap
> > to take actions of their own. If so, it then follows the address set
> > within process signal. (see /usr/proc/bin/psig...)

> Unless I'm very mistaken the kernel trap handler only gets involved when
> userland processes cause a trap, e.g by accessing unmapped memory (SIGSEGV)
> etc. For many signals, e.g SIGCHLD they are sent by the kernel straight to
> the process in question.

> Cheers,
> Shaun

Nope. Always thru Kernel Trap Handler. I've checked Solaris Internals
book.
 
 
 

which kernel process is actually responsible for receiving the Signals

Post by Shaun Clowe » Wed, 19 Mar 2003 09:16:33








> > > 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
(SIGSEGV)
> > etc. For many signals, e.g SIGCHLD they are sent by the kernel straight
to
> > 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).

Cheers,
Shaun

 
 
 

which kernel process is actually responsible for receiving the Signals

Post by Music Ma » Wed, 19 Mar 2003 14:31:05











> > > > 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
> (SIGSEGV)
> > > etc. For many signals, e.g SIGCHLD they are sent by the kernel straight
> to
> > > 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).

> Cheers,
> Shaun

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

Regards

 
 
 

1. sending signal sends -1 to the receiving process (question)

Hello,
  I have a question regarding signals.  This question occurs to me when
I'm trying to write a curses based package.  I'd like certain area on
the screen to blink, but SUN terminal does not support blinking (am I right?),
so I produce a child process and have the child process interrupt the parent
process, say, every 0.2 seconds, and then certain area on the screen changes
state accordingly (A related problem is, the visual effect produced in this way
is not really pleasing, is there any way to get around the problem?).  The
problem comes in when I notice that the parent process keeps receiving unwanted
characters.  This I did not know before; it looks like when a process sends a
signal to another process, it puts something in the other process's input
stream as well.  I tried to write a very much simplified program and then I
realized the problem has nothing to do with the cursor package.  I can get
around the problem because the unwanted character is always (char)(-1), so
I simply ignore that, but still I'm wondering what is the reason for this.
Anyone care to explain?  The programs are appended.
  BTW, if it is relevant, I'm using a SPARC IPC running SunOS 4.1 and
compiled the programs with /usr/5bin/cc and relevant libraries & includes,
where appropriate.
  Thanks in advance,
        Lite

========================================================================
#include <signal.h>

void blink();

main()
{
  int pid;
  char ch;

  if ((pid=fork()) == -1) {  /* forks off a process which would interrupt
                                once in a while; help do blinking */
    perror("fork");
    exit(1);
  }
  else if (pid == 0) {
    execl("/sol3/cs1/lin/599/sysv-nopad/nap", "nap", "2000000", (char *)0);
    perror("execl");
  }
  else
    signal(SIGALRM, blink);
  while (ch=getchar()) {
    printf("%d\n", ch); /* this prints -1 */
    printf("%c", ch);
  }

void blink()
{
  signal(SIGALRM, blink);
========================================================================

#include <signal.h> /* the "nap" program */
#include <sys/types.h>
#include <stdio.h>

main(argc, argv, envp)
int argc;
char *argv[], *envp[];
{
  int usec = 0;
  char *ptr;
  int ppid;

  ppid = getppid();
  ptr = argv[1];
  while (*ptr) {
    usec = usec*10 + *ptr - '0';
    ptr++;
  }
  for (;;) {
    usleep(usec);
    kill(ppid, SIGALRM);
  }

2. Tools for Shared Libraries in Slackware?

3. : meaning of "... received signal SIGWAITING, Process's LWPs are blocked."

4. drive LaserJet 5 from SS Voyager with infrared interface?

5. Receiving signals in daemon processes

6. Compex RL100/ATX and kernel 2.1.x

7. sending several signal to a process and only one is received

8. Linux - Gnome ICU - getting into "Away" automatically?

9. Fatal signal 11 received after receiving/losing IP address with ppp

10. Help receiving signal when data is received on socket

11. Identifying processes responsible for disk activity?

12. How to find process responsible for I/O

13. How would I know what processes are responsible for network slowdowns