Re: signal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jul 07, 2005 at 19:50:30 +0530, Gaurav Dhiman wrote:
> On 07 Jul 2005 12:34:15 +0530, Anurag Verma <averma@xxxxxxxxxxxxxxxxxxx> wrote:
> > Hi All
> > Can u please tell me when a process is busy in executing a system call,
> > and then another process sends a signal then what will happen to the
> > exectution of system call. Will it be interrupted ?
> 
> No, Signals are handled while returning from system calls or
> interrupts handlers. When process P1 is executing the system call code
> in kernel, and another process sends the signal to it, it kernel will
> give the controol to signal handler while returning from that system
> call or the interrupt handler (whatever the next interrupt occurs),
> whichever occurs first.
> 
> > If not then once the system call execution is finished then the signal
> > handler will be invoked?
> 
> Well it will be invoked before that only, because timer interrupts
> occur too freq and while returing from its handler, kernel will check
> the pending signals for currenly running process and invoke the
> registered signal handlers.

That's the case when the process is running in userland -- which was not
what the question asked about.

The answer is right, but there is a bit more to it. Signals are handled
during any return from kernel to userland. This can be during return
from syscall, return from interrupt or when the process was scheduled
(which is actually a special case of return from interrupt).

When a signal arrives during various syscalls, the system may behave
differently. For signals that don't sleep, the signal simply waits for
the syscall return, which will not last long.

Now when the syscall does sleep (many syscalls do, among them all IO),
it can sleep in interruptible or uninterruptible state. In the later,
the signal does not wake it up and has to wait for regular return. In
the interruptible sleep, the syscall is awoken and usually returns
prematurely.

It can return -EINTR, which is just passed to userland as errno value.
Or it can return magical -ERESTART or -ERESTARTNOHAND (perhaps the names
are bit different - look in errno.h). These cause the syscall to restart
after handling the signal, in the later case only if custom handler is
not installed.

-------------------------------------------------------------------------------
						 Jan 'Bulb' Hudec <bulb@xxxxxx>

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux