GHC IO 管理器支持哪些 IO 活动？
我一直在阅读 GHC 中新的 IO 管理器，它使用异步事件通知并避免阻塞 I/O 来实现高吞吐量。
哪些 IO 活动适合由新的异步 IO 代码管理？文件读写和网络活动？数据库访问？是否存在管理者必须诉诸阻塞的 IO 类型？
I've been reading about the new IO manager in GHC, which uses asynchronous event notifications and eschews blocking I/O to achieve high throughput.
Which IO activities are eligible for management by the new asynchronous IO code? Reading and writing of files and network activity? Database access? Are there kinds of IO where the manager has to resort to blocking?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
任何可以由
epoll/kqueue管理的文件描述符都是合格的。想要异步处理 I/O 的库需要与 I/O 管理器配合，方法是threadWaitRead和threadWaitWrite函数>GHC.Conc，然后重试之前返回EWOULDBLOCK的系统调用。这已经针对
Handle和Socket类型完成。如果您使用例如到 C 数据库库的绑定，您将获得阻塞行为，因为该库不会与 I/O 管理器合作。Any file descriptor that can be managed by
epoll/kqueueis eligible. Libraries that want asynchronous treatment of I/O need to cooperate with the I/O manager bythreadWaitReadandthreadWaitWritefunctions inGHC.Concbefore retrying a system call that previously returnedEWOULDBLOCK.This has already been done for the
HandleandSockettypes. If you use e.g. a binding to a C database library you will get blocking behavior as that library won't cooperate with the I/O manager.一个令人满意的答案：
新的 GHC IO 管理器的核心是 kqueue()/epoll() 事件循环。因此，我希望在此基础上构建的任何东西都符合资格——即使不是现在，也会是以后。特别是，这意味着：
代码（我几个月前查看过，事情可能已经改变）还包含通过优先级（搜索）队列注册和运行各种超时的支持。这表明大多数类似睡眠的调用也可以搭载在接口上。
关于数据库访问：当然，您经常通过网络 IO 套接字访问数据库，因此调用 forkIO 并在单独的线程中进行数据库访问应该是可行、快速且安全的。将数据传回应用程序的其余部分可以使用并发方式之一来完成：
Chan或STM.TChan。我不认为存在某种类型的 IO 管理器必须诉诸阻塞本身，但我可以想象一些库可能会绕过新的 IO 管理器并直接攻击要害。他们当然会阻止。
A somewhat satisfactory answer:
The heart of the new GHC IO manager is a
kqueue()/epoll()event loop. So I would expect anything which can be built on top of this to be eligible -- if not now, then later. In particular this means:The code (I looked at it some months ago and things might have changed) also contains support for registering and running timeouts of various kinds through a priority (search) queue. This suggest that most
sleep-like calls can also be piggybacking on the interface.About Database Access: sure, you often access the database through a network IO socket so calling
forkIOand doing DB access in a separate thread should be doable, fast, and safe. Communicating data back to the rest of the application can be done with one of the concurrency means,ChanorSTM.TChan.I don't think there are kinds of IO where the manager has to resort to blocking per se, but I can imagine that some libraries may circumvent the new IO manager and go straight for the jugular. They will, of course, block.