大约一年后，您可能想要研究的内容（您或其他通过搜索或 Google 找到此内容的人）是 libuv ，以前称为 liboio。与公认的答案相反，Windows 并不是（或者当时）缺乏事件化 I/O 的概念，只是它在 Windows API 的神秘圈子之外并不为人所知。开发商。在 Windows 领域，类似的概念被实现为 I /O 完成端口，所以 libeio 版本/端口/fork/analog 并不需要重新实现轮子，它只需要有一个类似 libeio 的 API 来支持在下面使用 IOCP 的东西引擎盖。
Almost a year later, what you may want to look into (you, or anyone else finding this via search or Google) is libuv, formerly liboio. Contrary to the the accepted answer, it's not so much that Windows is, or at the time was, bereft of the concept of evented i/o, it just wasn't well-known outside of the arcane circle of deep-knowledge Windows API developers. In the Windows space, a similar concept is implemented as I/O Completion Ports, so it's not so much that a libeio version/port/fork/analog would need to reimplement the wheel, it'd just have to have a libeio-looking API to something that was using IOCP under the hood.
当然，考虑到 libeio 唯一的 C 文件 eio.c 的大小相对较小，第二种解决方案是最好的解决方案。
Libeio is using unix APIs and unix concepts which are unknown on the Windows world. The solutions you have are :
use a unix abstraction layer on windows : like cygwin or Windows Services for Unix. But even with those layers, you'll have difficulties running libeio code as there are a lot of system-dependent code like this :
# if __FreeBSD__ || defined __NetBSD__ || defined __OpenBSD__
# define _DIRENT_HAVE_D_TYPE /* sigh */
# define D_INO(de) (de)->d_fileno
# define D_NAMLEN(de) (de)->d_namlen
# elif __linux || defined d_ino || _XOPEN_SOURCE >= 600
# define D_INO(de) (de)->d_ino
# endif
rewrite libeio with a portable abstraction library like GTK+ (glib in fact), wxWidgets or Qt. Thoses frameworks already implement powerful API for low level routines, communication services, i/o channels and asynchronous queues. Developers of those frameworks had made a lot of effort to allow portability of their code. You don't have to reinvent the wheel.
Definitely, the second solution is the best one, considering the relatively small size of eio.c, the only C file of libeio.
发布评论
评论（2）
大约一年后，您可能想要研究的内容（您或其他通过搜索或 Google 找到此内容的人）是 libuv ，以前称为 liboio。与公认的答案相反，Windows 并不是（或者当时）缺乏事件化 I/O 的概念，只是它在 Windows API 的神秘圈子之外并不为人所知。开发商。在 Windows 领域，类似的概念被实现为 I /O 完成端口，所以 libeio 版本/端口/fork/analog 并不需要重新实现轮子，它只需要有一个类似 libeio 的 API 来支持在下面使用 IOCP 的东西引擎盖。
Almost a year later, what you may want to look into (you, or anyone else finding this via search or Google) is libuv, formerly liboio. Contrary to the the accepted answer, it's not so much that Windows is, or at the time was, bereft of the concept of evented i/o, it just wasn't well-known outside of the arcane circle of deep-knowledge Windows API developers. In the Windows space, a similar concept is implemented as I/O Completion Ports, so it's not so much that a libeio version/port/fork/analog would need to reimplement the wheel, it'd just have to have a libeio-looking API to something that was using IOCP under the hood.
Libeio 使用的是 Windows 世界中未知的 unix API 和 unix 概念。您拥有的解决方案是：
当然，考虑到 libeio 唯一的 C 文件 eio.c 的大小相对较小，第二种解决方案是最好的解决方案。
Libeio is using unix APIs and unix concepts which are unknown on the Windows world. The solutions you have are :
Definitely, the second solution is the best one, considering the relatively small size of eio.c, the only C file of libeio.