signals in a single thread process. - Unix

This is a discussion on signals in a single thread process. - Unix ; Hi, I just wanted to know as to how signal works? My program is a single threaded, written in c and has registered a handler for a signal function. The main() of my program is in an infinite loop, now ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: signals in a single thread process.

  1. signals in a single thread process.

    Hi,

    I just wanted to know as to how signal works?

    My program is a single threaded, written in c and has registered a
    handler for a signal function. The main() of my program is in an
    infinite loop, now when the signal is generated, how does the control
    shift from the main's infinite loop to the signal handler. How exactly
    does the microprocessor manage to do (i'm assuming that there isn't
    any kind of context switch as the signal handler is a kind of library
    provided in the same process ).

    Thanks in advance !!!

  2. Re: signals in a single thread process.

    On Mar 13, 2:34 am, Rahul wrote:

    > My program is a single threaded, written in c and has registered a
    > handler for a signal function. The main() of my program is in an
    > infinite loop, now when the signal is generated, how does the control
    > shift from the main's infinite loop to the signal handler. How exactly
    > does the microprocessor manage to do (i'm assuming that there isn't
    > any kind of context switch as the signal handler is a kind of library
    > provided in the same process ).


    It does it the same way it does a context switch. It saves the current
    stack and registers, optionally switches to a different stack ands
    sets up the return from the signal handler to do the right thing, and
    then jumps to the signal handler.

    Let's look quickly at two different signals as examples:

    1) SIGSEGV/SIGFPE/SIGILL -- the program executes an instructions that
    causes a processor trap. In this case, the trap will generally invoke
    kernel code, saving the process' context so the kernel code can
    return. If there's a handler, the kernel will rejigger the context so
    it returns to the handler and the handler returns to just before the
    instruction that caused the fault in the first place.

    2) SIGINT/SIGKILL -- a signal is sent to the program from elsewhere
    while the process is not running. In this case, the kernel just has to
    modify the context of the process so that it is ready-to-run (if it
    wasn't before) and such that when it's next scheduled, it will
    "return" to the signal handler. The rejiggering is much like in 1
    above.

    This only really misses two major issues. One is if the process is
    currently running on another CPU. The other is if the process is
    currently blocked in some unusual place in the kernel, such as waiting
    for disk data to be read.

    The short answer to both of these cases is that the kernel marks the
    signal as "pending" to be delivered to the process and the kernel
    checks for pending signals before it returns to user-space from kernel-
    space.

    DS

  3. Re: signals in a single thread process.

    On Mar 13, 3:48 pm, David Schwartz wrote:
    > On Mar 13, 2:34 am, Rahul wrote:
    >
    > > My program is a single threaded, written in c and has registered a
    > > handler for a signal function. The main() of my program is in an
    > > infinite loop, now when the signal is generated, how does the control
    > > shift from the main's infinite loop to the signal handler. How exactly
    > > does the microprocessor manage to do (i'm assuming that there isn't
    > > any kind of context switch as the signal handler is a kind of library
    > > provided in the same process ).

    >
    > It does it the same way it does a context switch. It saves the current
    > stack and registers, optionally switches to a different stack ands
    > sets up the return from the signal handler to do the right thing, and
    > then jumps to the signal handler.
    >
    > Let's look quickly at two different signals as examples:
    >
    > 1) SIGSEGV/SIGFPE/SIGILL -- the program executes an instructions that
    > causes a processor trap. In this case, the trap will generally invoke
    > kernel code, saving the process' context so the kernel code can
    > return. If there's a handler, the kernel will rejigger the context so
    > it returns to the handler and the handler returns to just before the
    > instruction that caused the fault in the first place.
    >
    > 2) SIGINT/SIGKILL -- a signal is sent to the program from elsewhere
    > while the process is not running. In this case, the kernel just has to
    > modify the context of the process so that it is ready-to-run (if it
    > wasn't before) and such that when it's next scheduled, it will
    > "return" to the signal handler. The rejiggering is much like in 1
    > above.
    >
    > This only really misses two major issues. One is if the process is
    > currently running on another CPU. The other is if the process is
    > currently blocked in some unusual place in the kernel, such as waiting
    > for disk data to be read.
    >
    > The short answer to both of these cases is that the kernel marks the
    > signal as "pending" to be delivered to the process and the kernel
    > checks for pending signals before it returns to user-space from kernel-
    > space.
    >
    > DS


    Thanks for the comments.
    I understand the context switch when the handler is a default handler
    provided by the operating system for any kind of process, however what
    if the handler is registered by the process which itself is executing
    in the user-space.

    Ok let me be specific with an example,

    #include
    #include
    #include

    /* This flag controls termination of the main loop. */
    volatile sig_atomic_t keep_going = 1;

    /* The signal handler just clears the flag and re-enables itself.
    */
    void
    catch_alarm (int sig)
    {
    keep_going = 0;
    }

    void
    do_stuff (void)
    {
    puts ("Doing stuff while waiting for alarm....");
    }

    int
    main (void)
    {
    /* Establish a handler for SIGALRM signals. */
    signal (SIGALRM, catch_alarm);

    /* Set an alarm to go off in a little while. */
    alarm (2);

    /* Check the flag once in a while to see when to quit. */
    while (keep_going)
    do_stuff ();

    return EXIT_SUCCESS;
    }

    In other words, context switch across processes makes sense. But i
    really don't get the picture as to how it can happen within a process
    like the above one... the handler in the above example is loaded into
    the code segment of the process and it does access the variable
    keep_going which is present in data segment of the process...

    Thanks in advance!!!

  4. Re: signals in a single thread process.

    Rahul wrote:

    > In other words, context switch across processes makes sense. But i
    > really don't get the picture as to how it can happen within a process
    > like the above one...


    Context switch within a process can be considered a simple sub-set of
    context switch between processes.

    The OS stores the registers to the stack, loads a new set of registers
    (including a new program counter) and typically sets up the registers
    such that on return from the kernel the userspace app is running in the
    signal handler.

    If you're really curious about how this works, why not take a look at
    the code for linux or BSD?

    Chris

  5. Re: signals in a single thread process.

    On Mar 13, 7:22 pm, Chris Friesen wrote:
    > Rahul wrote:
    > > In other words, context switch across processes makes sense. But i
    > > really don't get the picture as to how it can happen within a process
    > > like the above one...

    >
    > Context switch within a process can be considered a simple sub-set of
    > context switch between processes.
    >
    > The OS stores the registers to the stack, loads a new set of registers
    > (including a new program counter) and typically sets up the registers
    > such that on return from the kernel the userspace app is running in the
    > signal handler.
    >
    > If you're really curious about how this works, why not take a look at
    > the code for linux or BSD?
    >
    > Chris


    I would love to... could you let me know how to get started?

+ Reply to Thread