非阻塞本机文件访问 - C中的单线程守护进程？

我发现本机文件访问没有“非阻塞”状态。（我是正确的？）非阻塞本机文件访问 - C中的单线程守护进程？

我一直在搜索“非阻塞”的守护进程，并且我发现了一个通过线程文件访问操作实现了上述行为的守护进程，因此守护进程不会阻止。

我的问题是，不会线程和IPC'ing这样的操作是相当昂贵的？对于以下两种情况来说，这样做是否更有意义？A）预线程池，只需让每个客户端在一个线程上并让它阻塞它可能需要的任何阻塞操作。或者，

B）在文件访问阻塞的情况下，使用一个相对较小的缓冲区，这样它仍然阻塞 - 但人们会认为多个操作的小缓冲区比支付每个操作的线程代价更有意义和IPC呢？

来源

2010-10-10 Doori Bar

一个通常使用所用系统上可用的C库。对于'非阻塞'文件访问，通常使用'select'，'poll'，'epoll'等完成。这些可用资源取决于系统/ C运行时。 – 2010-10-10 19:47:47

您确定这是本机文件的选项吗？（不是FIFO，也不是套接字）。不幸的是，我找不到任何相关的东西，如果你可以分享一个具体的参考，将非常感激！ – 2010-10-10 19:53:58

这不是普通文件的选项，选择/轮询始终报告总是可读/始终可写的文件。 – nos 2010-10-10 20:15:02

如果使用线程，则需要很少的IPC开销。你的所有线程都有相同的内存空间，所以你可能需要一个简单的互斥量或信号量。现在，如果你太长或太频繁地阻塞互斥体或信号量，为什么首先使用异步I/O？

至于执行I/O的线程执行的实际计算，他们正在等待内核在大部分时间唤醒它们，所以我不担心。

如果您的应用程序将围绕着读取文件和其他I/O资源，您可能需要阅读Reactor模式和事件驱动编程。

此外，你提到了一个守护进程，并为客户提供服务。如果你提供的服务是读文件，产生一个新的线程来服务每个客户端的计算成本是最小的，因为每个线程将花费很长的时间来完成请求，并阻止大部分时间。如果你的客户数量在成千上万，可能会有内存问题，但否则我认为你会做得很好。

给我们更多关于你想做什么的细节，也许有更直接的方法。

来源

2010-10-11 00:32:44 slezica

http://s3.amazonaws.com/four.livejournal/20091117/jsconf.pdf - 这个参考对我的问题有上下文。我想运行一个单线程的HTTP守护程序是有道理的，但是如果你为每个文件访问操作支付一个线程 - 那么我没有看到这一点。我错过了什么？他们为什么选择这条道路？ – 2010-10-11 06:12:27

非阻塞本机文件访问 - C中的单线程守护进程？

回答

相关问题