4

我不是新手,在编程时使用信号。我主要工作在C/C++和Python。 但我很想知道如何在Linux(或Windows)中实际实现信号。在Linux和Windows下实现信号?

如果有任何已注册的信号需要处理,操作系统是否会检查信号描述符表中的每条CPU指令?或者是流程管理者/调度员对此负责?

由于信号是异步的,CPU指令在完成之前是否中断?

+2

编辑帖子并删除各种大写。请不要使用此类外部源代码,因为它通常在互联网上被视为粗鲁(“大喊”)。 – Lundin

+0

两篇文章都非常有帮助:如何信号在Linux中实现(http://cs-pub.bu.edu/fac/richwest/cs591_w1/notes/wk3_pt2.PDF)和[Linux的信号处理模式(HTTP ://www.linuxjournal.com/article/3985) –

回答

6

操作系统绝对不会处理每条指令。没门。太慢了。

当CPU遇到问题时(如除法0,访问受限资源或未由物理内存备份的内存位置),它会生成一种特殊的中断,称为异常(不会混淆用C++/Java /等高级语言异常抽象)。

操作系统处理这些异常。如果需要,并且如果可能的话,它可以将异常反射回来源于它的过程。 Windows中所谓的Structured Exception Handling(SEH)就是这种反映。 C信号应该使用相同的机制来实现。

+0

谢谢回答!....我请你,请阅读http://cs-pub.bu.edu/fac/richwest/cs591_w1/notes/wk3_pt2 .PDF。这里描述的一些中断描述符表(IDT)也读取滑动数字18,表示'CPU执行每条指令后检查中断'。这是真的吗?......对我来说这一切都不清楚。 –

+1

IDT由OS配置,但它是从中取出ISR地址并在那里传输控制权的CPU。而且CPU是第一个检查中断的。检查代码中的中断效率非常低。这项工作最好由硬件完成,即CPU。如果您对中断和异常如何工作感兴趣,请阅读CPU手册(来自Intel或AMD)。它就在那里,包括指令之间的中断“交付”(是的,这是真的)。 –

+0

@Alexye Frunze:我在这里发布了一个问题:http://stackoverflow.com/questions/12437648/uninterruptable-program-on-window-linux ...我向你请求请看看并提出一些提示。 –

2

一个进程可以发送信号到另一个进程。进程可以注册自己的信号处理程序来处理信号。 SIGKILL和SIGSTOP是无法捕获的两个信号。

当进程执行信号处理程序,它的块相同的信号,这意味着,当信号处理程序是在执行时,如果另一相同信号到达时,它不会调用信号处理程序[称为阻塞信号],但它使注意信号已经到达[即:待处理信号]。一旦已经运行的信号处理程序被执行,然后处理待处理的信号。如果您不想运行未决信号,那么您可以忽略该信号。

在上述概念的问题是:

假定以下:用于SIGUSR1 过程A已注册的信号处理程序。

1) process A gets signal SIGUSR1, and executes signalhandler() 
    2) process A gets SIGUSR1, 
    3) process A gets SIGUSR1, 
    4) process A gets SIGUSR1, 

当步骤(2)发生时,它被设置为'未决信号'。即;它需要被服务。 并且当步骤(3)发生时,它被忽略,因为只有一个位 可用于指示每个可用信号的未决信号。

为了避免这样的问题,即:如果我们不想丢失信号,那么我们可以使用 实时信号。 。

2)的信号同步执行,

例如,

 1) process is executing in the middle of signal handler for SIGUSR1, 

    2) Now, it gets another signal SIGUSR2, 

    3) It stops the SIGUSR1, and continues with SIGUSR2, 
     and once it is done with SIGUSR2, then it continues with SIGUSR1. 

3)恕我直言,我记得如果有任何信号到达的过程检查是:

1) When context switch happens. 

希望这有助于延长。

4

在我所熟悉的(虽然我不明白为什么它应该是在其他地方太大的不同),信号传递是当过程从内核到用户模式返回完成的系统。

让我们首先考虑一个CPU的情况。有三个来源的信号:

  • 过程将信号发送到本身
  • 另一个进程发送信号
  • 中断处理程序(网络,磁盘,USB等)导致发送
  • 的信号

在所有这些情况下,目标进程没有在用户态运行,但在内核模式。无论是通过系统调用,还是通过上下文切换(因为除非我们的目标进程未运行,其他进程无法发送信号),或通过中断处理程序。所以信号传递是一个简单的事情,可以检查在从内核模式返回到用户区之前是否有任何信号要传递。

在多CPU的情况下,如果目标进程在另一个CPU上运行,它只是一个发送中断它的运行在CPU的问题。中断除了强制其他CPU进入内核模式并返回外,其他任何事情都不做任何事情,因此信号处理可以在返回时完成。