我实际上不知道我是否在问一个正确的问题。让我先描述一下我的问题。
最终用户＆lt; -1-＆gt;网络服务器（通过PHP）＆lt; 2-＆gt;内部过程（通过C或C ++）＆lt; -3-＆gt;外部硬件
1应该像ajax请求。 2应该是类似进程间通信的东西。 3应该是uart RS232通信。
最终用户将请求更改硬件上的某些设置，然后请求将传播到硬件。硬件回复成功或失败，然后结果将传播回用户。硬件回复延迟可以在1秒内。
因此，当Web服务器收到来自最终用户的ajax请求时，它将保存并向c / c ++程序发送IPC请求。 c / c ++程序将通过UART发送并保持并等待硬件回复。对于UART部分，有异步uart模型，因此c / c ++程序不需要连续等待UART。
网络服务器将一直等到c / c ++程序返回（再次通过IPC），然后将结果转发给最终用户。
由于webserver没有内存，所以不能有任何异步的东西（据我所知）。
我可以想到一种通过文件或数据库的简单方法。网络服务器不断读取文件或数据库以进行回复。
但我并不认为这是一个好方法，因为它会导致服务器CPU周期的浪费。
如果我能够容忍一些延迟，那么这取决于，但我认为用户端的几秒延迟对他们来说是好的。
你能否告诉我一些很好的IPC方法来达到我的目的？
而且，如果您认为整个过程或任何特定链接（包括链接1,2和3）有更好的解决方案（比我上面的描述），请分享您的2cent。
希望我能清楚地问我的问题。
感谢。
答案 0 :(得分：1)
您可以找到的最简单的解决方案是使用管道。这些过程将有一个开放的管道，用于读取“呼叫”并以相同的方式回答它们。
设置此方法的一种可能方法是在特定或可变位置放置一对命名管道（mkfifo）。这个过程和PHP都知道这样的管道。该过程将阻止在某些文本“协议”中读取请求/命令的循环，并通过另一个管道写回PHP。这样，PHP和外部进程都可以停止/终止并重新启动，通信路径仍然可以稳定。
如果需要，您可能需要执行其他操作以验证进程是否实际正在运行，但是对此“协议”的简单“ping”命令就足够了。
这假定：
当然还有其他方法可以实现这一目标，但我很难想到其他方式就像这样简单。排队（d-bus，其他），正如一些评论中所建议的那样，只是建立在这个想法之上，但增加了更多的复杂性，因此，如果不需要这些其他服务提供的功能，管道应该足够了。
答案 1 :(得分：1)
只需要我的2美分（应该是评论，但我没有声誉）使用zeromq或其他一些着名的排队库为你的ipc。
理论上，使用fifos和域套接字非常简单，但实际上，您需要编写许多边缘情况。例如，高水位标记，重新连接等。
答案 2 :(得分：0)