最佳IPC机制 [英] Best IPC mechanism to be used

查看:55
本文介绍了最佳IPC机制的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

假设我有5个独立的过程,分为两个想象的集合:

Suppose I have 5 independent process divided in two imaginay sets:

set1	set2
---------------------
p1	p3
|	|
p2	p4
	|
	p5



每个集合中的进程之间经常相互通信.
我的意思是p1和p2经常互相交流
同样,p3,p4和p5经常相互通信.

但是两组之间相互交流的频率较低
我的意思是p1和p2组偶尔会通信,很少与其他p3,p4和p5组通信.

哪种IPC机制最适合在每个集合中用于其中的过程,为什么?
哪种IPC机制最适合用于集合之间的通信,为什么?



The processes inside each set communicate mutually quite often.
I mean p1 and p2 communicate mutually quite often
Similarly p3, p4 and p5 communicate mutually quite often.

But the two sets communicate less often with each other
I mean set of p1 and p2 communicate occasionally and rarely with other set of p3, p4 and p5.

Which IPC mechanism will be best to use inside each set for process in them and why?
Which IPC mechanism will be best to use for communication between the set and why?

Linux specific IPC is supposed to be used.

推荐答案

一个简单的答案:对于非常通用的IPC方法,请使用套接字.从历史上看,在网络上使用套接字之前,套接字是作为IPC设施发明的.它们仍然可以作为IPC很好.

如果不考虑特定于应用程序的细节,这不是做出此类决定的最佳方法.

但是,您可以在上面对问题的评论中找到答案的主要部分.由于上述原因,您需要使用POSIX线程而不是单独的进程.您应该描绘出一般的应用场景,绘制流程图,用例,协作模式等.

进程间/线程间通信方法的完美选择取决于这些特定于应用程序的注意事项.

—SA
One quick answer: for a very universal IPC approach, use sockets. Historically, sockets were invented as an IPC facility, before using them on a network. They are still good as IPC.

This is not the best way to make such decision without consideration of application-specific detail.

However, you can find main part of my answer in my comments to the question, above. You need to thing about using POSIX threads instead of separate processes, by the reason I explained above. You should picture the general application scenario, draw flow diagrams, use cases, collaboration schema, etc.

The perfect selection of inter-process/inter-thread communication methods depends on those application-specific considerations.

—SA


这篇关于最佳IPC机制的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆