signal

signal

Post by Frank Cusac » Tue, 10 Jun 2003 06:40:07




Quote:> If my process call a system call and already in kernal mode.
> then I send a kill -9 to my process.
> The system will change to user mode and recive the signal?

No, the process must at least get to a pre-emption point (sorry, I
don't know the real word for this).  For some kernels (ie, non-
preemptible), I believe the system call must finish.  Only then is the
signal received.

Of course for -9 it doesn't actually return to user mode.

At least, this is my understanding.  I'm not an expert.

/fc

 
 
 

signal

Post by Enrico Strasse » Tue, 10 Jun 2003 07:15:33


It basically depends if the system call is blocking or not. If it is
not, this is simple because signals are (generally) handled at the end
of the syscall just before returning to user space. If it is blocking,
then a waiting  loop implements a periodic test for some condition to be
true or for some pending signals, then exits the loop in that case. The
scheduler can handle this too on behalf of the process.


>>If my process call a system call and already in kernal mode.
>>then I send a kill -9 to my process.
>>The system will change to user mode and recive the signal?

> No, the process must at least get to a pre-emption point (sorry, I
> don't know the real word for this).  For some kernels (ie, non-
> preemptible), I believe the system call must finish.  Only then is the
> signal received.

> Of course for -9 it doesn't actually return to user mode.

> At least, this is my understanding.  I'm not an expert.

> /fc


 
 
 

signal

Post by Juergen Heinz » Tue, 10 Jun 2003 08:00:44



> If my process call a system call and already in kernal mode.
> then I send a kill -9 to my process.
> The system will change to user mode and recive the signal?

[-]
To the best of my knowledge - no. All signals are handled before a
process state changes to user mode.

A snag might be that a lot of OS'es are called Unix while
they're more than less "sort of" *nix, so to be sure you may
need to ask in some "your OS and version here" specific group
as God knows what's all running out there in the wild.

Cheers,
Juergen

--
\ Real name     : Juergen Heinzl       \       no flames      /

 
 
 

signal

Post by Amri » Wed, 11 Jun 2003 12:42:39




> > If my process call a system call and already in kernal mode.
> > then I send a kill -9 to my process.
> > The system will change to user mode and recive the signal?

> No, the process must at least get to a pre-emption point (sorry, I
> don't know the real word for this).  For some kernels (ie, non-
> preemptible), I believe the system call must finish.  Only then is the
> signal received.

> Of course for -9 it doesn't actually return to user mode.

> At least, this is my understanding.  I'm not an expert.

> /fc

Pre - emption point is the place at which all the Kernel Data
Structures are consistent.

Amrith

 
 
 

signal

Post by Tom » Thu, 12 Jun 2003 01:25:41


solaris 7 & 8
> To the best of my knowledge - no. All signals are handled before a
> process state changes to user mode.

> A snag might be that a lot of OS'es are called Unix while
> they're more than less "sort of" *nix, so to be sure you may
> need to ask in some "your OS and version here" specific group
> as God knows what's all running out there in the wild.

> Cheers,
> Juergen

> --
> \ Real name     : Juergen Heinzl       \       no flames      /


 
 
 

1. Signal handlers are not reset after signal delivery

The man page for signal says

        Unlike on BSD systems, signals under Linux  are  reset  to
        their  default behavior  when  raised.  However, if you
        include <bsd/signal.h> instead of <signal.h> then signal is
        redefined as __bsd_signal and signal has the BSD
semantics.

However I tried the following simple program and found that if I install
a signal handler once, it remains installed over multiple deliveries of
the same signal. i.e. the signal does not get  reset to its default
behaviour when raised.

#include <stdio.h>
#include <signal.h>

void  handler( int x) {

        printf( "Got the signal\n");

main() {

        char c;
        signal(28, handler);

        sleep(3600);

        printf( "Woke up\n");
        sleep(3600);

and the I did 'kill -28 <pid>' twice. Both the times I got the
message from signal handler.

Can anyone help explain this contradiction or am I messing up
somewhere in the concepts?

Thanks,
-Kartik

2. Extract from Tar

3. Signal handling: signal() vs. sigaction()

4. mgetty and Digicom Scout Plus

5. blocking signals in signal handler -- True or False quiz

6. Is setuid a security risk?

7. ** POSIX signals limited to 32 signals?

8. apt archives

9. Registering signal inside signal handler

10. signal.c: wrong rt signals comment, 2.4.20-pre11

11. signal inside signal

12. trap "<new trap action>; $(get_old_trap SIGNAL)" SIGNAL

13. Registering client data on signal manager side andreceiving it in signal handler