为什么选择 DBusWatch？为什么不是 dbus_connection_read_write_dispatch？答案

【问题标题】：Why DBusWatch? Why not dbus_connection_read_write_dispatch?为什么选择 DBusWatch？为什么不是 dbus_connection_read_write_dispatch？
【发布时间】：2015-05-13 16:03:32
【问题描述】：

DBusWatch and DBusTimeout examples 提出了类似的问题，但没有给出原因？

谁能解释一下，为什么在dbus_connection_read_write_dispatch()可以读写的情况下使用DBusWatch函数？

【问题讨论】：

标签： dbus

【解决方案1】：

“dbus_connection_read_write_dispatch()”的 DBUS 文档说：

考虑这个函数的方式是它要么取得某种进展，要么阻塞。请注意，虽然它在 I/O 上被阻塞，但它不能被中断（即使被其他线程），这使得该函数不适用于不仅仅对收到的消息做出反应的应用程序。

在典型的实际应用程序中，它需要处理来自多个来源的事件。例如，它可以接受键盘输入并将输入转换为通过 DBUS 发送的数据库查询。如果程序在 DBUS 事件上阻塞，它将无法接受键盘输入。

函数本身不做读/写，它是读/写过程的主循环调度部分。

【讨论】：

如果我使用dbus_connection_read_write_dispatch() 的线程？能解决问题吗？
是的，但代价是您在不同的上下文中运行它。通常，事件驱动系统有一个调度上下文，并且处理程序都在同一个上下文中。现在你必须处理锁定的复杂性。