进程间通讯与设计模型

进程间通讯与设计模型

进程间通讯形式多样，锁，信号，共享内存，socket（inet,netlink,unix）,管道pipe,消息等

除了锁,信号传递的信息比较单一外。

共享内存,socket,pipe，msg都是传递的数据块。

下面讨论传递数据块的情况：

1 进程间通讯往往是，面向服务的设计，服务进程要向调用方进程返回处理结果。 调用方发送数据等待服务方返回结果。服务方对于数据的处理，理想是使用几个变量，几个结构体，数组等线性排列的数据，这样可以直接对结构化的进行数据处理。但是往往服务方要处理的是链表，树，hash链表等非线性数据，针对这种情况，由于数据块难以实现这种结构，所以服务提供方进程要首先做数据块到非线性数据的转换。

针对指针数据转换的设计：

struct list_head {

struct list_head *next, *prev;

};

数据在数据块中线性排列，next,prev等指针转换成对应的offset来表示，服务提供方只需要将offset重新计算得出在新进程内存空间中对应的指针值。这要求使用方在向对方通讯之前要做线性化设计，

    进程1   <--数据-->  进程2， 代码可以不共享，但是要做线性数据要转换成非线性数据。

针对链表可以这样优化,减少数据类型的设计。

如何减少进程间通讯： 通过动态链接库或者静态库来代码共享减少进程间通讯，这样数据提供方，直接在自己进程内部使用服务，从而避免了数据传递，如果某个处理是可能会阻塞的，那么需要考虑通过多进程来实现，或者定时器。

进程间通讯什么情况下不可避免：

  设计过程是面向数据的设计，即数据在各个进程间流转，数据本身记录了处理状态。

data-->进程1(加工步骤1) -->进程2(加工步骤2) --> ...

  这个是单向过程，进程1不需要进程2处理的结果。 

  面向数据的设计，什么情况下需要进程1和进程2分离，而不能合并成一个进程呢。 步骤2的处理时候会发生阻塞事件的情况下，需呀这样设计，如果加工步骤2会阻塞的话，两进程合并必然会阻塞，从而会影响步骤1处理下一个数据。