“握手”是如何进行的？ 通常与命名管道相关实施
我需要在一个小型 Linux 程序中实现握手类型协议，该程序使用命名管道与其他进程进行通信。 我在使用命名管道时搜索了握手类型协议的通用实现模式，但我无法找到任何结果......
我简直不敢相信没有模式可以做到这一点。 有人可以向我指出可能的资源吗？
坦白说，这是家庭作业，但实现这种模式并不是家庭作业。 我们需要解决作业代码中的问题，我相信这是一个可能的解决方案。 作业是用 C++ 实现的——但语言对我来说并不重要。 我只是不想重新发明轮子......
更新：我有一种感觉，这可能是用信号来实现的。
我所说的握手的意思是，子进程向其父进程报告它已准备好工作，但不会继续进行（即使管道中有东西），直到家长发出开始信号。 在我的工作理论中，我将有许多子进程需要报告就绪并等待来自父进程的go信号。
I need to implement a handshake type protocol in to a small Linux program that uses named pipes to communicate with other processes. I've searched for a general implementation pattern for a handshake type protocol when using named pipes but I've not been able to turn anything up...
I simply can't believe that there isn't patterns to do this. Can someone point me to a possible resource?
In full disclosure this is for homework but implementing this pattern isn't the homework. We need to solve a problem within the homework code and I believe this to be a possible solution. The homework is implemented in C++ -- but the languages doesn't matter to me. I just don't want to reinvent the wheel....
Update: I have a feeling that this might be implemented with signals.
What I mean by handshake is that a child process reports to it's parent process that it is ready for work but does not proceed (even if there is something in the pipe) until the parent gives the go signal. In my working theory, I will have many child processes that need to report ready and wait for the go signal from the parent.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在典型用法中，进程依赖于阻塞来握手。 写入进程打开管道进行写入，读取进程打开管道进行读取，无论哪个先发生都会阻塞，直到另一个进程打开其一侧。 这可以扩展到在读取器端使用非阻塞 IO。
命名管道对于一对一 IPC 最有用。 在一对多的情况下，您可能应该使用 UNIX 域套接字。
In typical usage, the processes rely on blocking to handshake. The writer process opens the pipe for writing, the reader process opens the pipe for reading, and whichever happens first blocks until the other process opens its side. This can be extended to use nonblocking IO on the reader side.
Named pipes are most useful for one-to-one IPC. In your one-to-many situation, you should probably use a UNIX-domain socket instead.