精华内容
下载资源
问答
  • signal

    2015-07-27 10:04:45
    转载自:http://www.cplusplus.com/reference/csignal/signal/ function signal void (*signal(int sig, void (*func)(int)))(int); Set function to handle signal Specifies a way to handle the ...

    转载自:http://www.cplusplus.com/reference/csignal/signal/

    function
    <csignal>

    signal

    void (*signal(int sig, void (*func)(int)))(int);
    Set function to handle signal

    Specifies a way to handle the signals with the signal number specified by sig.

    Parameter func specifies one of the three ways in which a signal can be handled by a program:

    • Default handling (SIG_DFL): The signal is handled by the default action for that particular signal.
    • Ignore signal (SIG_IGN): The signal is ignored and the code execution will continue even if not meaningful.
    • Function handler: A specific function is defined to handle the signal.


    Either SIG_DFL or SIG_IGN is set as the default signal handling behavior at program startup for each of the supported signals .

    Parameters

    sig
    The signal value to which a handling function is set. The following macro constant expressions identify standard signal values:

    macro signal
    SIGABRT (Signal Abort) Abnormal termination, such as is initiated by the abort function.
    SIGFPE (Signal Floating-Point Exception) Erroneous arithmetic operation, such as zero divide or an operation resulting in overflow (not necessarily with a floating-point operation).
    SIGILL (Signal Illegal Instruction) Invalid function image, such as an illegal instruction. This is generally due to a corruption in the code or to an attempt to execute data.
    SIGINT (Signal Interrupt) Interactive attention signal. Generally generated by the application user.
    SIGSEGV (Signal Segmentation Violation) Invalid access to storage: When a program tries to read or write outside the memory it has allocated.
    SIGTERM (Signal Terminate) Termination request sent to program.

    Each library implementation may provide additional signal value macro constants that can be used with this function.

    Notice that not all running environments are required to generate automatic signals, not even in the specific cases described above, although all running environments must deliver signals generated by a explicit call to the raise function.
    func
    A pointer to a function. This may either be a function defined by the programmer or one of the following predefined functions:

    SIG_DFL Default handling: The signal is handled by the default action for that particular signal.
    SIG_IGN Ignore Signal: The signal is ignored.

    If a function, it should follow the following prototype (with C linkage):
     
    void handler_function (int parameter);
     


    Return value

    The return type is the same as the type of parameter func.

    If the request is successful, the function returns a pointer to the particular handler function which was in charge of handling this signal before the call, if any. Or either SIG_DFL or SIG_IGN if before the call the signal was being handled by the default handler or was being ignored, respectivelly.

    If the function was not successful in registering the new signal handling procedure, it returns SIG_ERR and errno may be set to a positive value.

    Example

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    
    /* signal example */
    #include <stdio.h>      /* printf */
    #include <signal.h>     /* signal, raise, sig_atomic_t */
    
    sig_atomic_t signaled = 0;
    
    void my_handler (int param)
    {
      signaled = 1;
    }
    
    int main ()
    {
      void (*prev_handler)(int);
    
      prev_handler = signal (SIGINT, my_handler);
    
      /* ... */
      raise(SIGINT);
      /* ... */
      
      printf ("signaled is %d.\n",signaled);
      
    
      return 0;
    }
    signaled is 1.



    Data races

    Undefined: calling this function in a multi-threaded program causes undefined behavior.

    Exceptions (C++)

    No-throw guarantee: this function never throws exceptions.

    展开全文
  • Signal

    2014-03-28 20:31:48
    Signal Default Action Description SIGABRT A Process abort signal. SIGALRM T Alarm clock. SIGBUS A Access to an undefined portion of a mem-  ory obj

    Signals were introduced by the first Unix systems to allow interactions between User
    Mode processes; the kernel also uses them to notify processes of system events.

    A signal is a very short message that may be sent to a process or a group of processes.
    The only information given to the process is usually a number identifying the
    signal; there is no room in standard signals for arguments, a message, or other
    accompanying information.

    Signals serve two main purposes:
    • To make a process aware that a specific event has occurred
    • To cause a process to execute a signal handler function included in its code
    Of course, the two purposes are not mutually exclusive, because often a process
    must react to some event by executing a specific routine.

    Table 11-1. The first 31 signals in Linux/i386
    # Signal nameDefault action Comment POSIX
    1 SIGHUP TerminateHang up controlling terminal or processYes
    2 SIGINT TerminateInterrupt from keyboardYes
    3 SIGQUIT DumpQuit from keyboardYes
    4 SIGILL DumpIllegal instructionYes
    5 SIGTRAP DumpBreakpoint for debuggingNo
    6 SIGABRT DumpAbnormal terminationYes
    6 SIGIOT DumpEquivalent to SIGABRTNo
    7 SIGBUS DumpBus errorNo
    8 SIGFPE DumpFloating-point exceptionYes
    9 SIGKILL TerminateForced-process terminationYes
    10 SIGUSR1 TerminateAvailable to processesYes
    11 SIGSEGV DumpInvalid memory referenceYes
    12 SIGUSR2 TerminateAvailable to processesYes
    13 SIGPIPE TerminateWrite to pipe with no readersYes
    14 SIGALRM TerminateReal-timerclockYes
    15 SIGTERM TerminateProcess terminationYes
    16 SIGSTKFLT TerminateCoprocessor stack errorNo
    17 SIGCHLD IgnoreChild process stopped or terminated, 
    or got signal if tracedYes
    18 SIGCONT ContinueResume execution, if stoppedYes
    19 SIGSTOP StopStopprocess executionYes
    20 SIGTSTP StopStopprocess issued from ttyYes
    21 SIGTTIN StopBackground process requires inputYes
    22 SIGTTOU StopBackground process requires outputYes
    23 SIGURG IgnoreUrgent condition on socketNo
    24 SIGXCPU DumpCPU time limit exceededNo
    25 SIGXFSZ DumpFile size limit exceededNo
    26 SIGVTALRM TerminateVirtual timer clockNo
    27 SIGPROF TerminateProfile timer clockNo
    28 SIGWINCH Ignore Window resizingNo
    29 SIGIO TerminateI/O now possibleNo
    29 SIGPOLL TerminateEquivalent to SIGIONo
    30 SIGPWR TerminatePower supply failureNo
    31 SIGSYS DumpBad system callNo
    31 SIGUNUSED DumpEquivalent to SIGSYSNo

    Besides the regular signals described in this table, the POSIX standard has introduced
    a new class of signals denoted as real-time signals; their signal numbers range
    from 32 to 64 on Linux. They mainly differ from regular signals because they are
    always queued so that multiple signals sent will be received. On the other hand, regular
    signals of the same kind are not queued: if a regular signal is sent many times in
    a row, just one of them is delivered to the receiving process.

    A number of system calls allow programmers to send signals and determine how
    their processes respond to the signals they receive.

    Table 11-2. The most significant system calls related to signals
    System call Description
    kill( ) Send a signal to a thread group
    tkill( ) Send a signal to a process
    tgkill() Send a signal to a process in a specific thread group
    sigaction( ) Change the action associated with a signal
    signal( ) Similar to sigaction( )
    sigpending( ) Check whether there are pending signals
    sigprocmask( ) Modify the set of blocked signals
    sigsuspend( ) Wait for a signal
    rt_sigaction( ) Change the action associated with a real-time signal
    rt_sigpending( ) Check whether there are pending real-time signals
    rt_sigprocmask( ) Modify the set of blocked real-time signals
    rt_sigqueueinfo( ) Send a real-time signal to a thread group
    rt_sigsuspend( ) Wait for a real-time signal
    rt_sigtimedwait( ) imilar to rt_sigsuspend( )

    An important characteristic of signals is that they may be sent at any time to a process
    whose state is usually unpredictable. Signals sent to a process that is not currently
    executing must be saved by the kernel until that process resumes execution.
    Blocking a signal requires that delivery of the signal be held off until
    it is later unblocked, which exacerbates the problem of signals being raised before
    they can be delivered.

    Therefore, the kernel distinguishes two different phases related to signal transmission:
    Signal generation
    The kernel updates a data structure of the destination process to represent that a
    new signal has been sent.
    Signal delivery
    The kernel forces the destination process to react to the signal by changing its
    execution state, by starting the execution of a specified signal handler, or both.

    Each signal generated can be delivered once, at most. Signals are consumable
    resources: once they have been delivered, all process descriptor information that
    refers to their previous existence is canceled.

    Signals that have been generated but not yet delivered are called pending signals. At
    any time, only one pending signal of a given type may exist for a process; additional
    pending signals of the same type to the same process are not queued but simply discarded.
    Real-time signals are different, though: there can be several pending signals
    of the same type.

    In general, a signal may remain pending for an unpredictable amount of time. The
    following factors must be taken into consideration:
    • Signals are usually delivered only to the currently running process (that is, to the
    current process).
    • Signals of a given type may be selectively blocked by a process. In this case, the process does not
    receive the signal until it removes the block.
    • When a process executes a signal-handler function, it usually masks the corresponding
    signal—i.e., it automatically blocks the signal until the handler terminates.
    A signal handler therefore cannot be interrupted by another occurrence of
    the handled signal, and the function doesn’t need to be reentrant.

    Although the notion of signals is intuitive, the kernel implementation is rather complex.
    The kernel must:
    • Remember which signals are blocked by each process.
    • When switching from Kernel Mode to User Mode, check whether a signal for a
    process has arrived. This happens at almost every timer interrupt (roughly every
    millisecond).
    • Determine whether the signal can be ignored. This happens when all of the following
    conditions are fulfilled:
    — The destination process is not traced by another process (the PT_PTRACED flag
    in the process descriptor ptrace field is equal to 0).
    — The signal is not blocked by the destination process.
    — The signal is being ignored by the destination process (either because the
    process explicitly ignored it or because the process did not change the
    default action of the signal and that action is “ignore”).
    • Handle the signal, which may require switching the process to a handler function
    at any point during its execution and restoring the original execution context
    after the function returns.

    There are three ways in which a process can respond to a signal:
    1. Explicitly ignore the signal.
    2. Execute the default action associated with the signal (see Table 11-1). This
    action, which is predefined by the kernel, depends on the signal type and may be
    any one of the following:
    Terminate
    The process is terminated (killed).
    Dump
    The process is terminated (killed) and a core file containing its execution
    context is created, if possible; this file may be used for debug purposes.
    Ignore
    The signal is ignored.
    Stop
    The process is stopped—i.e., put in the TASK_STOPPED state.
    Continue
    If the process was stopped (TASK_STOPPED), it is put into the TASK_RUNNING
    state.
    3. Catch the signal by invoking a corresponding signal-handler function.

    Notice that blocking a signal is different from ignoring it. A signal is not delivered as
    long as it is blocked; it is delivered only after it has been unblocked. An ignored signal
    is always delivered, and there is no further action.

    The SIGKILL and SIGSTOP signals cannot be ignored, caught, or blocked, and their
    default actions must always be executed. Therefore, SIGKILL and SIGSTOP allow a user
    with appropriate privileges to terminate and to stop, respectively, every process,*
    regardless of the defenses taken by the program it is executing.

    There are two exceptions: it is not possible to send a signal to process 0 (swapper), 
    and signals sent to process 1 (init) are always discarded unless they are caught. 
    Therefore, process 0 never dies, while process 1 dies only when the init program terminates.

    A signal is fatal for a given process if delivering the signal causes the kernel to kill the
    process. The SIGKILL signal is always fatal; moreover, each signal whose default
    action is “Terminate” and which is not caught by a process is also fatal for that process.
    Notice, however, that a signal caught by a process and whose corresponding
    signal-handler function terminates the process is not fatal, because the process chose
    to terminate itself rather than being killed by the kernel.

    The POSIX 1003.1 standard has some stringent requirements for signal handling of
    multithreaded applications:
    • Signal handlers must be shared among all threads of a multithreaded application;
    however, each thread must have its own mask of pending and blocked signals.
    • The kill() and sigqueue() POSIX library functions must send signals to whole multithreaded
    applications, not to a specific thread. The same holds for all signals
    (such as SIGCHLD, SIGINT, or SIGQUIT) generated by the kernel.
    • Each signal sent to a multithreaded application will be delivered to just one
    thread, which is arbitrarily chosen by the kernel among the threads that are not
    blocking that signal.
    • If a fatal signal is sent to a multithreaded application, the kernel will kill all
    threads of the application—not just the thread to which the signal has been
    delivered.

    In order to comply with the POSIX standard, the Linux 2.6 kernel implements a
    multithreaded application as a set of lightweight processes belonging to the same
    thread group.

    Thread groups were added to support the POSIX threads notion of a set of threads that share a single PID.  
    Internally, this shared PID is the so-called thread group identifier (TGID) for the thread group.  
    Since Linux 2.4, calls to getpid(2) return the TGID of the caller.
    The threads within a group can be distinguished by their(system-wide) unique thread IDs (TID).  
    A thread can obtain its own TID using gettid(2).

    Furthermore, a pending signal is private if it has been sent to a specific process; it is
    shared if it has been sent to a whole thread group.

    For each process in the system, the kernel must keep track of what signals are currently
    pending or masked; the kernel must also keep track of how every thread group
    is supposed to handle every signal. To do this, the kernel uses several data structures
    accessible from the process descriptor. 

    Figure 11-1. The most significant data structures related to signal handling

    The sigaction data structure:

    sa_handler
    This field specifies the type of action to be performed; its value can be a pointer
    to the signal handler, SIG_DFL (that is, the value 0) to specify that the default
    action is performed, or SIG_IGN (that is, the value 1) to specify that the signal is
    ignored.
    sa_flags
    This set of flags specifies how the signal must be handled; some of them are
    listed in Table 11-6.
    sa_mask
    This sigset_t variable specifies the signals to be masked when running the signal
    handler.

    Table 11-6. Flags specifying how to handle a signal
    Flag Name Description
    SA_NOCLDSTOP Applies only to SIGCHLD; do not send SIGCHLD to the parent when the process is stopped
    SA_NOCLDWAIT Applies only to SIGCHLD; do not create a zombie when the process terminates
    SA_SIGINFO Provide additional information to the signal handler
    SA_ONSTACK Use an alternative stack for the signal handler
    SA_RESTART Interrupted system calls are automatically restarted
    SA_NODEFER,SA_NOMASK Do not mask the signal while executing the signal handler
    SA_RESETHAND,SA_ONESHOT Reset to default action after executing the signal handler

    A child that terminates, but has not been waited for becomes a "zombie".  
    The kernel maintains a minimal set of information about the zombie process(PID, termina-tion status, 
    resource usage information) in order to allow the parent to later perform a wait to obtain information 
    about the child. As long as a zombie is not removed from the system via a wait, it will consume a slot 
    in the kernel process table, and if this table fills, it will not be possible to create further processes. 
    If a parent process terminates, then its "zombie" children (if any) are adopted by init(8), which 
    automatically performs a wait to remove the zombies.

    POSIX.1-2001 specifies that if the disposition of SIGCHLD is set to SIG_IGN or the SA_NOCLDWAIT flag 
    is set for SIGCHLD (see sigaction(2)), then children that terminate do not become zombies and a call to 
    wait() or waitpid() will block until all children have terminated, and then fail with errno set to ECHILD. 
    (The original POSIX standard left the behaviour of setting SIGCHLD to SIG_IGN unspecified.) Linux 2.6 
    conforms to this specification.  However, Linux 2.4 (and earlier) does not: if a wait() or waitpid() call 
    is made while SIGCHLD is being ignored, the call behaves just as though SIGCHLD were not being ignored, 
    that is, the call blocks until the next child terminates and then returns the process ID and status of that child.


    来源:Understanding The Linuxkernel 3rd.Edition
    展开全文
  • Signal机制

    2020-09-08 22:32:36
    其中Signal主要使用了静态方法Signal.handle(Signal, SignalHandler),而SignalHandler是一个接口,有一个抽象方法void handle(Signal var1);需要我们自己实现SignalHandler接口处理。 在Linux下支持的信号(具体...

    信号(signal)是一种进程间通信机制,它给应用程序提供一种异步的软件中断,使应用程序有机会接受其他程序活终端发送的命令(即信号)。应用程序收到信号后,有三种处理方式:忽略,默认,或捕捉。进程收到一个信号后,会检查对该信号的处理机制。如果是SIG_IGN,就忽略该信号;如果是SIG_DFT,则会采用系统默认的处理动作,通常是终止进程或忽略该信号;如果给该信号指定了一个处理函数(捕捉),则会中断当前进程正在执行的任务,转而去执行该信号的处理函数,返回后再继续执行被中断的任务。

    Java中提供了Signal的机制,Signal机制在Linux中是一个非常常用的进程间通信机制。在sun.misc包下,属于非标准包。重要涉及到两个类:Signal和SignalHandler。其中Signal主要使用了静态方法Signal.handle(Signal, SignalHandler),而SignalHandler是一个接口,有一个抽象方法void handle(Signal var1);需要我们自己实现SignalHandler接口处理。

    在Linux下支持的信号(具体信号kill -l命令查看):
    SEGV, ILL, FPE, BUS, SYS, CPU, FSZ, ABRT, INT, TERM, HUP, USR1, USR2, QUIT, BREAK, TRAP, PIPE

    kill  -15  ${pid} 来杀死程序,这样,在jvm退出的时候,会将ShutdownHook中的内容执行一遍,这样就可以在里面定义自己的资源释放(一般是连接池)的操作了 。

    不要使用kill -9  ${pid}  ,这个会直接杀死jvm的进程,hook是来不及执行的,kill后面的数字参数如下:

    HUP     1    终端断线
    INT     2    中断(同 Ctrl + C)
    QUIT    3    退出(同 Ctrl + \)
    TERM    15   终止
    KILL    9    强制终止
    CONT    18   继续(与STOP相反, fg/bg命令)
    STOP    19   暂停(同 Ctrl + Z)
    
    默认的kill参数是 -15 (TERM) .

    在Windows下支持的信号:

    SIGINT(INT)     Ctrl+C中断

    SIGILL (ILL)      非法指令

    SIGFPE(FPE)      浮点异常

    SIGSEGV(SEGV)   无效的内存引用

    SIGTERM(TERM)   kill发出的软件终止

    SIGBREAK(BREAK) Ctrl+Break中断

    SIGABRT(ABRT)   调用abort导致

    一、信号类型

    Linux系统共定义了64种信号,分为两大类:可靠信号与不可靠信号,前32种信号为不可靠信号,后32种为可靠信号。

    • 不可靠信号: 也称为非实时信号,不支持排队,信号可能会丢失, 比如发送多次相同的信号, 进程只能收到一次. 信号值取值区间为1~31;

    • 可靠信号: 也称为实时信号,支持排队, 信号不会丢失, 发多少次, 就可以收到多少次. 信号值取值区间为32~64

    一、首先看下java中Signal枚举有哪些各代表什么含义:每个新号都对应一个整数值 

    SIGUSR1 (USR1):用户自定义信号1(10) 默认处理:进程终止
    SIGUSR2 (USR2):用户自定义信号2(12) 默认处理:进程终止

    推荐:用户自定义信号USR1和USR2,其他信号我同事说可能会隐患别的问题,最好不用.

    TERM:终止信号(15)

    KILL:Kill信号(9)

    INT:键盘中断(2)

    HUP :终端挂起或者控制进程终止(1)

    BUS:总线错误(7)

    上面这5个出现的比较多,下面是其他的信号

    ALRM:警告

    CHLD:子进程结束信号

    CONT:进程继续(曾被停止的进程)

    FPE:浮点异常

    ILL:非法指令

    IO:某I/O操作现在可以进行了

    IOT:IO捕获指令

    PIPE:管道破裂: 写一个没有读端口的管道

    PROF:Profiling定时器到

    PWR:电源故障

    QUIT:键盘的退出键被按下

    SEGV:无效的内存引用

    STKFLT:协处理器堆栈错误

    STOP:终止进程

    TRAP:跟踪/断点捕获

    TSTP:控制终端(tty)上按下停止键

    TTIN:后台进程企图从控制终端读

    TTOU:后台进程企图从控制终端写

    VTALRM: 实际时间报警时钟信号

    WINCH:窗口大小改变

    XCPU:超出设定的CPU时间限制

    XFSZ:超出设定的文件大小限制

    二、信号产生

    信号来源分为硬件类和软件类:

    2.1 硬件方式

    • 用户输入:比如在终端上按下组合键ctrl+C,产生SIGINT信号;
    • 硬件异常:CPU检测到内存非法访问等异常,通知内核生成相应信号,并发送给发生事件的进程;

    2.2 软件方式

    通过系统调用,发送signal信号:kill(),raise(),sigqueue(),alarm(),setitimer(),abort()

    • kernel,使用 kill_proc_info()等
    • native,使用 kill() 或者raise()等
    • java,使用 Procees.sendSignal()等

    Linux中signal机制的模型:

    每个进程都会采用一个进程控制块对其进行描述,进程控制块中设计了一个signal的位图信息,其中的每位与具体的signal相对应,这与中断机制是保持一致的。当系统中一个进程A通过signal系统调用向进程B发送signal时,设置进程B的对应signal位图,类似于触发了signal对应中断。发送signal只是“中断”触发的一个过程,具体执行会在两个阶段发生:

    1、  system call返回。进程B由于调用了system call后,从内核返回用户态时需要检查他拥有的signal位图信息表,此时是一个执行点。

    2、  中断返回。进程被系统中断打断之后,系统将CPU交给进程时,需要检查即将执行进程所拥有的signal位图信息表,此时也是一个执行点。

    综上所述,signal的执行点可以理解成从内核态返回用户态时,在返回时,如果发现待执行进程存在被触发的signal,那么在离开内核态之后(也就是将CPU切换到用户模式),执行用户进程为该signal绑定的signal处理函数,从这一点上看,signal处理函数是在用户进程上下文中执行的。当执行完signal处理函数之后,再返回到用户进程被中断或者system call(软中断或者指令陷阱)打断的地方。

     Signal机制实现的比较灵活,用户进程由于中断或者system call陷入内核之后,将断点信息都保存到了堆栈中,在内核返回用户态时,如果存在被触发的signal,那么直接将待执行的signal处理函数push到堆栈中,在CPU切换到用户模式之后,直接pop堆栈就可以执行signal处理函数并且返回到用户进程了。Signal处理函数应用了进程上下文,并且应用实际的中断模拟了进程的软中断过程。

    import sun.misc.*;
    
    @SuppressWarnings("restriction")
    public class TestSignal implements SignalHandler {
    
        public void handle(Signal arg0) {
            System.out.println(arg0.getName() + "is recevied.");
            System.exit(0);
        }
    }
    
    import sun.misc.*;
    
    public class App {
        @SuppressWarnings("restriction")
        public static void main(String[] args) {
            TestSignal handler = new TestSignal();
            Signal.handle(new Signal("TERM"), handler);
            Signal.handle(new Signal("INT"), handler);
            Signal.handle(new Signal("ILL"), handler);
            for (;;) {
                System.out.println("do something");
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }
    }

    深入JVM关闭与关闭钩子

    Java虚拟机退出包括两个阶段:

    第一个阶段:会以某种未指定的顺序启动所有已注册钩子,并且允许它们同时运行直至结束

    第二个阶段:如果已启用runFinalizersOnExit设置为true,则运行所有未调用的终结方法(finalizer方法)

    System.exit()底层调用的Runtime.getRuntime().exit(),调用后终止当前正在运行的Java虚拟机。参数作为状态代码,按照惯例,一个非零状态码表示异常终止。

    前面说到, Signal的一大作用是关闭进程, 然而Java提供了Shutdown Hook(关闭钩子)机制,它让我们在程序正常退出或者发生异常时能有机会做一些清场工作。

    关闭钩子使用的方法也很简单,Runtime.getRuntime().addShutdownHook(Thread hook)即可。关闭钩子其实可以看成是一个已经初始化了的但还没启动的线程,当JVM关闭时会并发地执行注册的所有关闭钩子

    JVM的关闭方式可以分为三种:

    • 正常关闭:当最后一个非守护线程结束或者调用了System.exit或者通过其他特定平台的方法关闭(发送SIGINT,SIGTERM信号等)
    • 强制关闭:通过调用Runtime.halt方法或者是在操作系统中直接kill(发送SIGKILL信号)掉JVM进程
    • 异常关闭:运行中遇到RuntimeException异常, OOM错误等。

    注意: Hook线程在JVM 正常关闭才会执行,在强制关闭和异常关闭时不会执行。Spring在初始化容器的时候就会注册一个hook线程用于清理容器.

    • 不能在钩子调用System.exit(),否则卡住JVM的关闭过程,但是可以调用Runtime.halt()。halt方法不会执行钩子函数和finalizer方法,而是直接退出。
    • 不能再钩子中再进行钩子的添加和删掉操作,否则将会抛出IllegalStateException。
    • System.exit()之后添加的钩子无效。
    • 当JVM收到SIGTERM命令(比如操作系统在关闭时)后,如果钩子线程在一定时间没有完成,那么Hook线程可能在执行过程中被终止。
    • Hool线程中同样会抛出异常,如果抛出异常又不处理,那么钩子的执行序列就会被停止。
    展开全文
  • 彻底掌握Quartus——Signaltap篇

    万次阅读 多人点赞 2016-11-25 16:24:35
    如果你用过Signaltap,就会发现,每次都要综合整个工程,再下载代码,然后才可以使用Signaltap,这说明了Signaltap是由一些逻辑电路组成,而不是仿真。 请不要把Signaltap和Modelsim混为一谈(如果是...

    一、前言。

    Signaltap是嵌入式逻辑分析仪,说到嵌入式,很容易让人想起ARM,其实Signaltap跟ARM没有半毛钱关系。这里的嵌入是嵌到FPGA的内部。

    如果你用过Signaltap,就会发现,每次都要综合整个工程,再下载代码,然后才可以使用Signaltap,这说明了Signaltap是由一些逻辑电路组成,而不是仿真。

    请不要把Signaltap和Modelsim混为一谈(如果是一样的话,就不用起两个名字了),就算两个软件的界面上的波形很像。

    以下是Signaltap界面上的波形(代表实际的波形)。

    以下是Modelsim界面上的波形(代表仿真的波形)。

    二、基本操作。

    首先,要确保你的工程能成功综合,并且所消耗的资源不能为0。

    然后在Quartus界面下,点开Tools菜单,打开Signaltap。

    在Signaltap界面下,确保Jtag和FPGA开发板能用。

    设置主时钟,点击红色箭头所指的地方。

    在Filter下,一般是选择Post-Compliation(综合后)。

    点击List,可以看到节点名。

    可以看到由原理图或者HDL文件的节点名了,这里选择clk50M。

    这个clk50M不是随便选的,是原理图上的全局时钟,这里用晶振的时钟做为Signaltap的采样时钟,你也可以选PLL倍频后的时钟,这都是看具体情况而定。

    选择采样深度,也就是采多少个点,这也是看具体情况而定,深度越大,需要的资源越多,这里选择128。

    确保已选中Setup标签(红色箭头所指,选中为白色,未选中为灰色),然后双击红圈所示区域。

    Filter同样选择综合后,同样点List列出所有节点。

    选择你想要观察的节点,这里选的是dig和segment。

    dig和segment,同样在原理图(或者HDL文件)中有出现过的,是有效的节点名。

    成功添加节点的话,会在Setup和Data标签下,出现下图所示。

    好了,现在你可以在Quartus界面下,点Save all以保存所有文件,然后综合,再到Signaltap界面下,选择sof文件,下载(红色箭头所示的图标)。

    成功下载sof的话,可以看到Ready to acquire。而Instance Manager右边有四个图标,分别代表单次运行,连续运行,停止和读数据。

    点连续运行,就能看到Signaltap在采集数据了(数据在不断地跳,难以观察)。

    如果你不停止掉Signaltap,是不能综合代码的。

    因为使用Signaltap,所以会额外消耗更多的资源,如果不想使用Signaltap的话,可以在Assignments->Settings设置一下,如下图所示。

    只要去掉Enable SignalTap II Logic Analyzer前面的勾就可以了,这样,综合出来的电路就不带Signaltap了(资源会减少)。

    三、高级操作。

    1、条件触发。

    先停止Signaltap,然后在Setup标签下,勾选条件触发下面的Basic AND,然后在下面输入想要的触发条件,这里填的是EF,意思是当dig(8bit)为十六进制的EF时,就会触发Signaltap采样,而其它情况不触发。其中Basic AND是所有触发条件相与之后为真,就触发采样,当然也可以选择Basic OR(相或为真就触发采样)和Advanced。

    如果不满足触发条件,Signaltap就一直显示Waiting for trigger。

    一般用上面的方法设置条件触发就够用了,如果有特殊要求,就用Signal Configuration下的条件触发,会有更强大的功能。

    2、文件输出。

    在File->Export,可以把Signaltap采样到的数据,保存为其它格式的文件,其中有csv,tbl,bmp,jpg,vcd,这五种格式可选。其中csv格式适合配合MATLAB使用。

    3、数据格式。

    在需要观察的节点上,右击。

    然后在Bus Display Format下,可以选择不同的数据格式,以方便观察。其中unsigned/signed line chart是用来观察连续信号的波形,如DDS下的sin/cos,或者是FSK,QAM等。

    4、设置时间单位。

    在红色箭头所指的地方,右击一下,选择Time Units,可以设置时间单位。

    我这里的采样时钟是50M,所以,周期是20ns。

    这样,Signaltap每采一个数据,所需要的周期就是20ns。为什么这个时间单位需要人手设定?就是因为Signaltap不带频率计的功能(下面在Signaltap内部原理有讲述)。

    5、MATLAB与Signaltap联合使用。

    首先,要把signaltap运行起来,采集到数据。

    然后,在MATLAB下,添加quartus的bin文件的路径(32位的添加bin,64位的添加bin64),然后调用alt_signaltap_run函数就可以了,但是我这里却找不到该函数,实际是有这个dll的,路径也添加正确,该方法未果。

    四、Signaltap内部原理。

    上图是signaltap的内部结构图,它是利用JTAG边界扫描的原理来读取FPGA内部节点的值,然后送到buffer(缓冲器),再由JTAG把数据送到quartus下的signaltap软件。

    整个过程,都只有读取数据的作用,至于数据的频率(如DDS下的sin信号的频率)是无法直接知道的,只能让设计者自己计算得出。

    五、其它问题。

    1、为什么在clk50M下面,会产生clk50M~clkctrl这个信号?

    在工艺映射表(适配后),可以查看到这个信号。

    其实clk50M~clkctrl就是clk50M的buffer而已,用于提高扇出系数,这里fan-out=274。

    2、为什么加了Signaltap之后,原来能用的代码,变得不能用?

    因为Signaltap本身需要占用一些逻辑资源,而这些逻辑资源影响了综合器的布局布线,所以有些时候加了Signaltap,时序反而乱了。不过,也有加了Signaltap时序变好的情况。

    3、既然Signaltap采出来的信号是实际的波形,但是某些时候却跟实际的不相符?

    就算是用Signaltap采出来的波形,也是需要遵循采样定理的,如果不满足采样定理,那么采出来的波形不能代表实际的波形。

    而且Signaltap里面的触发器本身有滤波的作用,所以有些很小的毛刺,采不到,但是用示波器可以看出来。

    展开全文
  • Linux signal那些事儿

    2017-03-29 15:57:56
    signal
  • Signal Box

    2017-04-28 13:52:47
    Signals are specified by a line "S I F B" where S stands for "Signal" (German for signal), I is the identifier of the signal, and F and B give the identifiers of the front and back elements of the ...
  • Linux Signal

    2017-04-26 15:24:11
    Linux signal
  • Signal: SIGTRAP (signal SIGTRAP)问题解决 在jni开发时,调试时遇到Signal: SIGTRAP (signal SIGTRAP)导致程序老是卡在某几个语句,无法正常调试。 后来发现是由于,我的jni借口函数返回值为boolean,而我在程序...
  • signal函数

    2016-08-04 17:36:42
    signal注册函数
  • Django signal

    2018-09-27 10:17:13
    这不是大神的随笔,只是记忆力不好的码农笔记 ...什么是django的signal 官方文档描述如下: Django includes a “signal dispatcher” which helps allow decoupled applications get notified when actions...
  • Python之signal模块详解

    万次阅读 2018-06-05 23:43:50
    先简单说一下Signal是啥.(如果想直接使用可以不看)Signal翻译过来中文就是信号- -当然, 本身他就是Linux系统编程中非常重要的概念, 信号机制是进程之间传递消息的一种机制,其全称为软中断信号作用是通知进程发生了...
  • linux signal

    千次阅读 2016-03-24 14:11:03
    最近同事的程序设计过程中用到了Linux的signal机制,从而引发了我对Linux中signal机制的思考。Signal机制在Linux中是一个非常常用的进程间通信机制,很多人在使用的时候不会考虑该机制是具体如何实现的。signal机制...
  • SignalCatcher

    千次阅读 2017-12-27 17:26:50
    一、SignalCatcher 线程的启动1.1 StartSignalCatcherruntime.ccvoid Runtime::InitNonZygoteOrPostFork( JNIEnv* env, bool is_system_server, NativeBridgeAction action, const char* isa) { ... ...
  • python signal详解

    2020-08-05 14:59:43
    import sys import signal def quit(signum, frame): print(’’) print(‘stop fusion’) sys.exit() if name == “main”: logger.info(“Starting mysql remote ...#signal.signal(signal.SIGINT, quit) #sign
  • RECEIVED SIGNAL 15

    千次阅读 2020-03-10 11:31:40
    DFSRouter: RECEIVED SIGNAL 15: SIGTERM ERROR org.apache.hadoop.hdfs.server.namenode.NameNode: RECEIVED SIGNAL 15: SIGTERM 二、分析 1、signal 15含意是使用不带参数的kill命令时终止进程,初步判断,由于文件...
  • python signal

    2016-11-08 20:24:52
    Python】简单聊进程间异步通信之signal模块 Linux 信号是Unix系统中常见的一种进程间通信方式(IPC),例如我们经常操作的 kill -9 pid 这里的 -9对应的就是 SIGKILL 信号, 9就是这个信号的编号,...
  • signal模块简介

    2019-03-05 14:13:00
    signal模块简介 最近在看Linux signal 相关内容,signal可以被用来进程间通信和异步处理。Python标准库提供了signal包可以用来处理信号相关。这里讨论的是Unix系统中Python的signal模块。 signal简单示例 官方...
  • signal and system

    2010-09-06 16:21:31
    signal and system lx signal and system lx signal and system lx signal and system lx signal and system lx signal and system lx signal and system lx signal and system lx signal and system lx signal and ...
  • QML signalsignal handler系统

    千次阅读 2013-07-09 14:21:24
    QML 的signalsignal handler机制的存在,是为了应用能够和UI组件之间相互交互。signal就是button clicked、mouse area pressed这些event,signal handler则就是这些事件的响应。 当一个signal emitted,相应的...
  • go signal简单示例

    千次阅读 2018-11-16 20:27:51
    os/signal" "syscall" ) func main() { fmt.Println("main is running") sc := make(chan os.Signal, 1) signal.Notify(sc, syscall.SIGINT, syscall.SIGTERM, s...
  • Linux signal捕获

    2019-01-14 09:36:33
    signal的原理这里不打算多讲,这里主要讲一下应用 man 7 signal,可以看到一些关于signal的介绍: 每个信号都对应着一个action,默认的有:Term, Ign,core,Stop,Cont, 文档上明确的写着是以进程为修改单位的,...
  • 精通Signaltap

    2018-06-15 14:42:07
    一、前言。 Signaltap是嵌入式逻辑分析仪,说到嵌入式,很...如果你用过Signaltap,就会发现,每次都要综合整个工程,再下载代码,然后才可以使用Signaltap,这说明了Signaltap是由一些逻辑电路组成,而不是仿...
  • 函数signal

    2015-01-25 11:51:19
    UNIX系统信号机制最简单的接口是signal函数。 #include void (*signal(int signo, void (*func)(int)))(int); 返回值:若成功,返回以前的信号处理配置;若出错,返回SIG_ERRsigno参数如下。 fun

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 72,905
精华内容 29,162
关键字:

signal