转载时请注明出处和作者联系方式：http://blog.csdn.net/absurd

作者联系方式：Li XianJing <xianjimli at hotmail dot com>

更新时间：2006-12-19

signal是GObject的重要特色，也是GTK+的基本支柱。它的原理其实很简单，基于订阅/发布模式，用于解耦消息的发送者和接受者。在D-BUS的帮助下，signal还可以跨进程传递(当然，这同时也让事情变得有些复杂了)。无论是使用现有对象的signal，还是实现新对象的signal，都是很简单的事，一般不会遇到什么问题。但有时几个问题搅在一起后，容易造成一些假象，让人防不胜防。最近一些同事遇到几个关于signal的问题，我花了一些时间调试，这里总结一下。

1. marshal函数实现错误。Glib只实现了极少的marshal函数，大部分情况下都要自己编写，尽管编写marshal函数不算复杂，但初学者仍然容易犯错，常见的错误是参数个数n_param_values没有包括对象自身，结果让marshal函数认为参数个数不匹配。幸运的是，glib提供了一个小工具glib-genmarshal，它可以产生marshal函数，输入是一个marshal的描述文件，输出marshal函数的实现。下面是一个描述文件的示例：

依次为返回值和参数列表。

使用示例：

glib-genmarshal --body marshal.list

2. 错误的signal ID。一个同事遇到一个奇怪的问题：在对象的成员函数内触发signal工作正常，而D-BUS的回调函数里触发signal就会失败。我想D-BUS的回调函数也是从mainloop里调过来的，都在同一个线程执行，不会有什么问题。用gdb跟踪到g_signal_emit_valist里，发现LOOKUP_SIGNAL_NODE (signal_id)返回的node并不属于当前对象，对比正常和异常两种情况，发现两者的signal_id不一样。查看相关代码，确认是两个同名的全局变量引起的问题。

3. 错误的对象。另外一个同事遇到一个更神奇的问题：在对象的成员函数内触发signal工作正常，而source的dispatch函数里触发signal就会失败，更奇怪的是默认处理函数调用正常，而通过D-BUS连接过来的客户端收不到signal。由此可见，即不是marshal函数的问题，也不是signal ID的问题。我怀疑是D-BUS传输出了错，跟踪signal_emitter_marshaller à D-BUS_connection_sendà_D-BUS_connection_send_preallocated_unlocked_no_update à_D-BUS_connection_do_iteration_unlockedàdo_writingàwritev，发现消息成功的写入socket了。

再看客户端代码，客户端是在message_queue_dispatch函数里分发D-BUS消息的，而这个函数一直没有被调用，也就是说D-BUS服务器没有把消息转发过来。猜想原因有两种，消息错误，或者目标不对。消息出错的可能性不大，也没有任何出错信息。在函数signal_emitter_marshaller里把对象的path打印出来，发现正常和异常两种情况的path不一样：原来是两个不同的对象实例。查看相关代码，确认是逻辑上的错误。

后两个问题的原因与signal没有什么关系，只是BUG的现象正好表现在signal上，加上有D-BUS这样的复杂玩意儿掺合，很容易把搞人蒙了。其实遇到这种问题不要着急，回忆一下signal的传递流程，设置几个关键检查点，如g_signal_emit_valist和signal_emitter_marshaller，很快就可以从现象追踪到本质。

~~end~~