libeio on windows

Question

What would it take to port libeio to windows?

Answer 1

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.

Answer 2

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.