glib信号与系统信号一些理解

用 LINUX 也有一段时间了 , 一直用 gtk, 看到 glib 下面有 gsignal, 在 linux 下面又有 signal 定义的信号回调之类的 , 看起来很像 , 但是又不怎么像 , 感觉有点模糊这之间到底有何关系呢？花了时间看了一下稍微总结一下 :

1.               他们之间无必然联系 ,gsignal 是 glib 自定义一套信号集合系统 , 所谓的这个系统是运行在用户态 , 完全不会执行内核的上下文切换，而且你可以理解成 , 同步回调。而 signal 是内核支持的 64 种事件的系统调用 , 所谓系统调用则一旦发生会进入内核去查找相应需要发送的进程去通知他们进行回调注册。

2.               为什么 signal 定义的叫事件 ,gsignal 定义的叫信号？ 在这里事件一般认为是外部触发的 , 能够唤醒进程进行调度的 , 而信号则不具备这样能力 , 只是内部回调实现的一个机制命名为信号。这里所说均特指 glib 中。在 glib 中 mainloop 在循环监测事件，其实并不监测 signal ，因为 signal 一旦 emit 将直接访问全局 signal 链表查找匹配的回调直接调用了，而无机会进入 loop 循环。

3.               那所谓的异步监测事件是什么，是 glib 本身提供对系统 signal 的封装，就是说他支持外部事件队列，就是监测一个 FD 上的 IO 操作之类，然后一旦 glib 本身捕获到这个事件后，解析一下打包成标准的 gsignal 信号发送，异步是异步在捕获外部事件这个层面，而不在 gsignal 的发送上。

4.               那到底 gsignal 发送和 signal 发送有什么不一样，其实实现过程就是原理大致相同，把信号放到队列中，然后检测是否可以发送，而后回调指定的回调。但是要区别的是 gsignal 运行在用户空间，而 signal 运行在内核空间，虽然原理一样，但是一旦回调注册的回调函数，那就是完全不同的， gsignal 因为在同一个进程下会直接知道地址进行调用，而 signal 不行只能通过中断唤醒相应进程还要压入参数等等进行回调。 Gsignal 使用二叉树行进排列 signal 节点因为 signalid 也是一个 int 数据依次递增，使用二叉树查找排序的消耗比较稳定一些。而 signal 应该并没有用特殊的数据结构，它只是与进程紧密绑定，所有进程包含一个 signal 等相关结构体来标志目前监控那些信号， block 了那些信号，还有其信号的回调是否默认或者 ignore 还是用户调用等等等等状态，而且普通的信号不能被多次 pending 就是说信号不能没有调用就又生成了。

5.               说下 signal 发送过程，其实系统事件处理分为两步 generate ， delivery ，生成阶段只是在内核相应的进程的 signal 的结构中标志一下我有这个信号需要处理就跑路了，而发送阶段一般在后面系统调用发送后内核会检测进程里面是否有信号准备完毕了可以满足条件发送了？满足了就进行中断进入用户空间调用。在这中间要射没射的就是 pending 状态，你只能搞完了才能来接活工作。 Rt 处理则不一样，这个不在讨论只列。而 gsignal 也有 pending 列表，这个什么状况原来不是说信号发送是同步的吗？还需要嘛个链表缓存信息啊，实际情况是 pending 我认为是由外部事件触发引起的，因为外部事件触发后如果没机会执行，只能消息片缓存在那边，等到工作忙完了一看已经有好多事件在那边了，怎么办？那就进行缓存按照优先级进行排队。进入 loop 循环一个一个调用 pending 的里面的事件进行处理。虽然 gsignal 也处理外部事件，我认为其处理还有封装自己的一些业务在里面并不是说一来就直接回调了，得按照 gsignal 统一得设计来做，排队，按优先级一个一个做。不忙那就另当别论。