与处理异步信号相比，我试图找到处理同步信号（SIGSEGV，SIGILL等）的资源。处理同步信号
的典型的信号处理机制（使用kill，例如）调用来自内核的控制转移到用户模式信号处理程序。我的理解是，'同步'信号更像是系统调用，因为控制器会立即传输到内核 - 可能是因为同步信号通常与CPU中断（内存保护等）相关联，并且无论如何都会调用内核处理程序。
libc函数是否是'async-signal-unsafe'安全地用于同步信号处理程序？例如，我看到Linux mprotect（2）手册页在SIGSEGV处理程序中使用printf。我怎样才能确定一个函数是否可以在这些情况下使用？
如何同步信号的一个典型的类Unix内核的处理来自其处理异步信号的有什么不同？什么使他们“同步”？
没有同步和异步信号，但某些信号是异步传送的，而另一些信号则可传送同步或异步信号。
交付始终是相同的：如果设置在用户模式下的信号处理程序被调用。如果未设置，则使用默认行为（默认行为是终止进程，除了某些忽略或暂停的信号）。
信号被认为是如果它们被一些外部原因引发的异步地传送（例如别人叫kill）。在这种情况下，从过程的角度来看，在发射和传输之间有时间：过程可以执行许多事情...
如果检测到某个信号应该是某个内部运行时间原因，则会同步传递信号发射。例如，一个坏的存储器访问，其可以提供SIGSEGV或SIGBUS，浮点错误等被零除其递送SIGFPE，坏指令（SIGILL）等。在这样的情况下，它是当前执行的代码/指令是故障源，然后立即发出信号然后传递。在这种情况下，从过程的角度来看，在排放和交付之间什么也没有发生。
同步与异步传送如何影响程序的异步信号安全性？考虑Linux上的man mprotect（2）'中的程序。处理程序在使用异步信号不安全功能时是否不正确？ –
是的，在任何**信号处理程序中使用异步信号不安全函数都是不正确的，因为你永远不知道信号的发生是否同步。 （1）某些外部事件可能产生SIGFPE（例如），因此您的进程无法知道它是否同步（2）您永远不知道是否在发生同步传送时允许对异步不安全功能的调用。所以**不要在信号处理程序中调用异步信号功能**。 –
我认为最好的资源之一，在那里是：
这里有两部分。信号的产生和信号的接收。程序通过信号处理程序接收信号。就信号处理器而言，信号的接收总是异步的（即，它不能预测何时将接收到）。
是否产生信号是同步的或异步是另一个问题。来自外部设备的中断显然是异步的。来自程序的调用信号将阻止该程序，直到调用返回。在呼叫期间，可以异步地发送信号（即，将其置于接收节目的队列中）或同步地（即，信号程序的处理程序被调用，并且信号程序/线程被暂停，直到处理程序返回，可能返回一些值。）例如，Windows SendMessage（同步）和PostMessage（异步）
此外：“中断从外部设备显然是异步“并暂停当前正在运行的进程，直到处理程序已完成。因此，分段冲突（硬件中断）暂停当前正在运行的进程（产生硬件信号）。其默认处理将终止该过程。
例如，如果当前进程暂停在SIGSEGV上，执行其他不安全的函数（例如'printf'）是否安全？即使被暂停，当前进程是否仍然持有锁（例如）？ –
不允许调用printf（至少行为是未定义的）。除了有关信号管理（信号掩码等）的一些事情之外，信号传递在全局状态过程中不做任何事情。所以锁定锁，仍然锁定... –
信号处理正如前面提到的评论是同步和异步的。同步意味着进程/线程会执行一些指令，并且这个执行导致了中断。 forex int * a; printf（“％d”，* a）;会导致分段错误。 异步： - 客户端进程和服务器进程示例：-server正在关闭，它将向客户端发送停止信号。客户端不会产生任何来自外部进程的中断。 每当出现同步中断时，就意味着进程出了问题。建议尽可能不要处理任何库或复杂语句。假设中断是由于malloc失败造成的，比再次使用某些库函数时会造成问题。更好的方法是在信号处理程序本身中自动重新启动进程。
定义的信号是不是异步？ –
我不确定。这表示有两种类型：ftp://ftp.gnu.org/old-gnu/Manuals/glibc-2.2.3/html_chapter/libc_24.html。 –