是否可以对 IPC 使用 glib 事件循环？
是否可以在一个父-多子进程模型中使用 glib 事件循环和 glib io 通道进行 IPC？
父母和孩子必须能够互相发送“命令”。
您能给我一些教程或示例吗？
Is it possible to use glib event loops and glib io channels for IPC in one parent - many child process model?
Parent and children must be able to send each other 'commands'.
Can you point me to some tutorials or examples?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的。但它本身并不包含完整的 IPC 解决方案，并且可能无法与现有的每个 IPC 实现完美兼容。对于父母和孩子，我猜你指的是服务器和客户端？通常，您打开某种网络连接或创建通信管道，然后获得一个文件描述符（即使您使用隐藏此的高级库）。您可以将此文件描述符传递给 glib 并获取回调，然后数据可供读取（或连接关闭）。一些流行的 IPC 方法，例如 CORBA 和 DBUS 已经具有 glib 集成，因此您甚至不需要费心处理文件描述符等。 此处描述了 glib 事件循环。与直接使用 poll() 相比，它可能看起来非常复杂，但另一方面它非常可移植。
基本用法是使用 g_source_new() 创建源，并使用 g_source_attach() 将其添加到主上下文，然后使用 g_source_add_poll() 将文件描述符添加到源。
如果你还没有决定使用 glib，你可能想看看 libevent 具有相同的功能东西像glib一样，但（恕我直言）更容易使用。它在处理 1000 多个并发客户端方面也明显更好（至少在 Linux 中，其他操作系统甚至可能不支持）。但另一方面，它不那么便携，并且可能只能在相当 posix 兼容的系统上工作。
Yes. But it doesn't contain a complete IPC solution in itself and is probably not perfectly compatible with every IPC implementation out there. With parent and children I guess you mean server and clients? Generally you open some sort of network connection or create pipe for communication and you get a file descriptor (even if you use a high level library that hides this). You can pass this file descriptor to glib and get a callback then data is available for reading (or the connection closed). Some popular IPC methods like CORBA and DBUS already has glib integration so you don't even need to bother with file descriptors and such. The glib event loop is described here. It might seem utterly complex compared to just using poll() directly but on the other hand it is very portable.
The basic usage is to create a source with g_source_new() and add it to your main context with g_source_attach() and then add your file descriptor to the source with g_source_add_poll().
If you havn't decided on glib yet you might want to check out libevent with does the same thing as glib but is (IMHO) much easier to use. It is also significantly better at handling 1000+ simultanious clients (at least in Linux, other operating systems may not even support that). But on the other hand it's not as portable and will probably only work on fairly posix compatible systems.