使用文件作为两个进程之间通信的方式有哪些缺点？
我有遗留代码，出于性能原因需要改进。我的应用程序包含两个需要交换某些信息的可执行文件。在遗留代码中，一个 exe 写入文件（文件名作为参数传递给 exe），第二个可执行文件首先检查此类文件是否存在；如果不存在，再次检查，当找到它时，然后继续读取文件的内容。通过这种方式，信息可以在两个可执行文件之间传输。根据代码的结构方式，第二个可执行文件在第一次尝试时就成功了。
现在我必须清理这段代码，并且想知道使用文件作为通信手段而不是像管道这样的进程间通信有什么缺点。打开和读取文件比管道更昂贵吗？还有其他缺点吗？您认为性能下降的影响有多大？
遗留代码可以在 Windows 和 Linux 上运行。
I have legacy code which I need to improve for performance reasons. My application comprises of two executables that need to exchange certain information. In the legacy code, one exe writes to a file ( the file name is passed as an argument to exe) and the second executable first checks if such a file exists; if does not exist checks again and when it finds it, then goes on to read the contents of the file. This way information in transferred between the two executables. The way the code is structured, the second executable is successful on the first try itself.
Now I have to clean this code up and was wondering what are the disadvantages of using files as a means of communication rather than some inter-process communication like pipes.Is opening and reading a file more expensive than pipes? Are there any other disadvantages? And how significant do you think would be the performance degradation.
The legacy code is run on both windows and linux.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
使用文件进行 IPC 的一些问题是：
当进程 (1) 正在写入文件而进程 (2) 找到该文件时会发生什么？您需要有特殊的逻辑来处理这种情况。
如果进程 (1) 希望在进程 (2) 仍在读取文件时发送另一条消息，会发生什么情况？ (1) 必须以某种方式检测到该文件无法写入，并等待它可用。
在大量消息流量下，文件可能会成为瓶颈，尤其是当您仅使用单个文件进行 IPC 时。
为了确定文件 I/O 是否是您的性能瓶颈，我们需要更多地了解您正在发送的消息。它们有多大，发送的频率等等。否则很难判断它们对你的性能有什么影响（如果有的话）。
也就是说，我过去曾使用文件在进程之间传递信息，尽管通常每次都会创建新的文件名，或者文件将用于传递大量数据，并且较小的 IPC 消息将用于在文件发生时发出信号准备好了。
在我看来，除非你有理由使用文件 - 例如传输大量数据 - 我更喜欢传统的 IPC 机制，例如管道、套接字等。但是你必须仔细实现它以确保一切正常两个平台。
Some problems with using files for IPC are:
What happens when process (1) is writing to the file when process (2) finds it? You need to have special logic to handle this case.
What happens if process (1) wishes to send another message while process (2) is still reading from the file? (1) would have to somehow detect that the file cannot be written to, and wait until it is available.
Files could become a bottleneck under large amounts of message traffic, especially if you are only using a single file for IPC.
To determine if file I/O is a performance bottleneck for you, we need to understand more about the messages you are sending. How large they are, how frequently they are sent, etc. Otherwise it is difficult to judge what affect they have on your performance, if any.
That said, I have used files in the past to pass information between processes, although typically either new filenames will be created each time or files will be used to pass large amounts of data and a smaller IPC message will be used to signal when the file is ready.
In my opinion unless you have a reason to use files - such as transfers of large amounts of data - I would prefer a traditional IPC mechanism such as pipes, sockets, etc. But you would have to implement it carefully to make sure everything works on both platforms.
我经常遇到此类设置的一个问题是对文件的访问同步，例如，当第二个文件尝试读取时第一个进程仍在写入，反之亦然。根据您的要求，这可能会导致各种不良行为。
使用真正的 IPC 机制总是好的，但如果您的应用程序必须跨平台，那确实会限制您的选择。
One issue I've frequently faced with such kind of setups is the synchronization of access to the file, for e.g. if the first process is still writing when the second file tries to read or vice versa. Depending on your requirements this can lead to all sorts of bad behavior.
It's always nice to use a real IPC mechanism but if your app has to be cross-platform, that really limits your choices.