Docstoc

signal

Document Sample
signal Powered By Docstoc
					    Signals and Session
       Management
          Chapter 4




1
               Contents
     Signal Generation and Handling
     Unreliable Signals
     Reliable Signals
     Signals in SVR4
     Signals Implementation
     Exceptions
     Process Groups and Terminal
      Management
     The SVR4 Sessions Architecture

2
        4.2 Signal Generation & Handling
     Signal: A way to call a procedure when some
      events occur.
     Generation: when an event occurs.
     Delivery: when the process recognizes the
      signal’s arrival (handling)
     Pending: between generated and delivered.
     System V: 15 signals
     4BSD/SVR4 : 31 signals
     Signal numbers: different in different system
      or versions
3
               Signal Handling
       Default actions: each signal has a ~.
         Abort: Terminate the process after generating a
          core dump.
         Exit: Terminate the process without generating a
          core dump.
         Ignore: Ignores the signal.
         Stop: Suspend the process.
         Continue: Resume the process, if suspended

       Default actions may be overridden by signal
        handlers. (p86)

4
                   Signal Handling
     Any  action can only be done by the process.
     issig() (Kernel call)
         Before  returning to user mode from a system call or
          interrupt.
         Just before blocking on an interruptible event
         Immediately after waking up from an interruptible
          event
       psig(): dispatch the signal
       sendsig(): invoke the user-defined handler


5
                   Signal Handling
                      Signal
                      delivered
    Execute normal code                     Resume normal code




                          Signal handler runs




6
            Signal Generation
     Signal   sources:
       Exceptions:
       Other  processes:
       Terminal interrupts:
       Job control:
       Quotas:
       Notifications:
       Alarms:


7
               Typical Scenarios
     ^C
     Exceptions:
       Trap:
          issig(): when return to user mode.
     Pending     signals: processed one by
     one.



8
            Sleep and signals
     Interruptiblesleep: is waiting for an
      event with indefinite time.
     Uninterruptible sleep: is waiting for a
      short term event such as disk I/O
       Pending    the signal
       Recognizing it until returning to user mode
        or blocking on an event
       if (issig()) psig();


9
             4.3 Unreliable Signals
      Signal handlers are not persistent and
       do not mask recurring instances of the
       same signal.(SVR2)
      Racing: two ^C.
      Performance: SIG_DFL, SIG_IGN,
        Kernel does not know the u_signal[];
        If SIG_IGN: Awake, check, and go back to
         sleep again(waste of time).

10
            Reinstalling a signal handler
        void sigint_handler(sig)
        int sig;
        { signal(SIGINT, sigint_handler);
           …
        }
        main()
        { signal(SIGINT, sigint_handler);
           …
        }//sig.c

11
               Reliable Signals
      Primary   features:
        Persistent  handlers: need not to be
         reinstalled.
        Masking: A signal can be masked
         temporarily.(remember it)
        Sleeping processes: let the signal
         disposition info visible to the kernel.(kept in
         the proc)
        Unblock and wait: sigpause()-automatically
         unmasks a signal and blocks the process.

12
           The SVR3 implementation
     int sig_received = 0;
     void handler (int sig)
     {
      sig_received++;
     }
     main()
     {
     sigset (SIGQUIT, handler);
     sighold(SIGQUIT);
     while (sig_received ==0) sigpause(SIGINT);
     }//sig1.c

13
                  4.5 Signals in SVR4
        sigprocmask(how, setp, osetp)
          SIG_BLOCK,      SIG_UNBLOCK, SIG_SETMASK
        sigaltstack(stack, old_stack):
          Specify   a new stack to handle the signal
        sigsuspend(sigmask)
          Set   the blocked signals mask to sigmask and puts
             the process to sleep
        sigpending(setp)
            setp contains the set of signals pending to the
             process


14
                Signals in SVR4
        sigsendset(procset, sig)
          Sends the signal sig to the set of processes
           procset
        sigaction(signo, act, oact)
          Specify a handler for signal signo.
          act -> a sigaction structure
          oact a function that returns the previous sigaction
          data
         Compatibility interface: signal, sigset,
         sighold, sigrelse, sigignore, sigpause (sig.txt)
15
               Signal flags
      SA_NOCLDSTOP:        Do not generate SIGCHLD
       when a child is suspended
      SA_RESTART: Restart system call
       automatically if interrupted by this signal
      SA_ONSTACK: Handle this signal on the
       alternate stack, if one has been specified by
       sigaltstack
      SA_NOCLDWAIT: sleep until all terminate
      SA_SIGINFO: additional info to the handler.
      SA_NODEFER: do not block this signal
      SA_RESETHAND: reset the action to default
16
             4.6 Signals Implementation
      The   info needed for kernel:
          u_signal[]: vector for handlers
          u_sigmask[]: masks associated with handlers
          u_signalstack: Pointer to the signal stack
          u_sigonstack: mask of signals
          u_oldsig: set of handlers exhibits the old behavior
          p_cursig: The current signal being handled
          p_sig: Pending signals mask
          p_hold: Blocked signals mask
          p_ignore: Ignored signals mask

17
              Signal Generation
     1.   Check(Kernel)
     2.   ignored?return:adds the signal to
          p_cursig.
     3.   Interruptible sleep & !blocked? Wake
          up the process: nothing.
     4.   SIGSTOP or SIGCONT suspend or
          resume


18
                        Delivery and Handling
     Checks by issig()
        If (1 bit(p_cursig) set)
        {if ( ! p_hold )
              {store the signal number in p_sig, return TRUE}
        else
             {psig()}
                 psig(){
                 If (no handler) default;
                 else invoke a handler {
                 if (! SA_NODEFER) change p_hold;
                 If (SA_RESETHAND) u_signal[] is reset to SIG_DFL;
                 }
                  sendsig(); //machine-dependent}

19
                 4.7 Exceptions
      An event when a program encounters an
       unusual condition(error).
      Using signals to notify.
          SIGSEGV
        Exceptions are used by debuggers.
            ptrace: a system call
        Drawbacks:
          Same  context for signal handler and exception
          Signals are for single-threaded processes.
          ptrace-based debugger can control only its
           immediate children
20
          4.9 Process Groups and
          Terminal Management
      Common     Concepts
       Process   groups: group-ID, leader
       Controlling terminal: login terminal
       The /dev/tty file: associated with the
        controlling terminal
       Controlling group: the group associated
        with a terminal.
       Job control: mechanism that can suspend
        or resume, or control the access to the
        terminal.
21
                    The SVR3 Model
      Process      groups
        inherits   the process group id during fork
      Controlling     terminal
        Owned      by its controlling group.
      Typical    scenario
        init   fork a child, the login shell is the leader
      Terminal access: no job control
      Terminal signals: ^Z, ^C, fg only
      Detaching the terminal: t_pgrp = 0
      Death of group leader: exit
      Implementation: proc, u area,
22
     Process groups in SVR3 UNIX




23
                              Limitations
   No way to close its controlling terminal and allocate
    another.
   No way to preserve a login session after disconnecting
    from its controlling terminal.
   No consistent way of handling “loss of carrier” by a
    controlling terminal.
   The kernel does not synchronize access to the terminal
    by different proceses in the group.
   When the group leader terminates, the kernel sends a
    SIGHUP signal to all processes in the group.
   If a process invokes setpgrp, it will be disconnected from
    the controlling terminal.
   No job control facilities.
   A terminal emulator has no way of receiving carrier loss
24 notification.
             4.10 The SVR4 Sessions
             Architecture
        Motivation:
          Supporting  both login session and job abstraction
          Providing BSD style job control
          Retaining backward compatibility
          Allowing a login session to attach and detach
           several controlling terminals
          Making the session leader responsible fro
           maintaining the session’s integrity and security.
          Allowing terminal access based solely on file
           access permissions.
          Eliminating inconsistencies of earlier
           implementation.
25
              Sessions and Process Group
      Createa session: setsid makes the caller
      the leader of both the session and the
      group.
        fggroup and bg group
        Inherit group:

      Change  a session: by setpgid(pid, pgid)
      Move: within a session
      Leave a session: by setsid


26
     SVR4 Sessions Architecture




27
              Data Structure
         setsid : allocates a new session
         structure and resets the p_sessp &
         p_pgidp in the proc.




28
29
               Controlling Terminals
      Login
        Calls setsid to become a session leader
        Close stdin, stdout, stderr
        Calls open to open a designated terminal
        Duplicates this descriptor elsewhere
        Opens /dev/tty as stdin, and duplicates
         stdout, and stderr
        Close the saved descriptor


30
              Controlling Terminals
      The session leader is a trusted process.
      The driver sends SIGTSTP to fg process
       group.
      A session leader may disconnect the
       current controlling terminal and open a
       new.
      When the session leader terminates, it
       ends the login session.

31

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:5
posted:8/14/2012
language:English
pages:31