Better Windows backend using wepoll?

[Linus Yang]

Dear libev authors and the community,

Libev has relatively weaker support on Windows than other Unix-like
platforms (Linux, BSD and macOS) due to the complexity of IOCP event
model.

Recently, Bert Belder (@piscisaureus on Github) released an epoll-like
library for Windows, called wepoll [1], that wraps IOCP APIs. One can
seamlessly use epoll APIs on Windows with high performance. The recent
version has fixed some LSP (Layered Service Provider) compatibility
issues and should be quite stable for normal use.

Note that with the existence of LSP dlls (e.g., Anti-virus software,
Proxifier, etc.), libuv on Windows silently falls back to a "slow
mode" that uses select() as backend. Such issue does not come with the
latest version of wepoll. Also, wepoll is significantly more
lightweight and very friendly to embed inside a project, just by
copying two source files (.c and .h).

I tried to port shadowsocks-libev [2] to MinGW using wepoll. The libev
library only needs very few changes [3] to use wepoll as backend. We
currently maintain a local fork of libev and prefer if such change
could go upstream.

Do you have any interest or opinions on integrating the wepoll library
inside libev for better Windows support?

Thanks!

[1] https://github.com/piscisaureus/wepoll
[2] https://github.com/shadowsocks/shadowsocks-libev
[3] https://github.com/shadowsocks/libev/commits/mingw

[Chris Brody]

Thanks for the response, didn't mean to ask in private. I think this would
make a really nice option, would recommend you post a patch to this effect.

Considering that I am not the owner I cannot make the decision.

Chris

https://www.linkedin.com/in/chrisbrody/

Can you elaborate on what improvements we get by building libev on

wepoll for Windows?

I do not understand what improvements wepoll offers over using plain

socket API besides better code portability.
Performance gain. Currently, libev on Windows uses select() as the
polling backend, which has O(n) time complexity.
Wepoll uses IOCP to simulate epoll-like APIs [1], which is more
efficient than select() and should achieve O(1) time complexity.
[1] https://github.com/piscisaureus/wepoll/blob/master/README.md

Can you elaborate on what improvements we get by building libev on wepoll
for Windows?
I do not understand what improvements wepoll offers over using plain

socket

API besides better code portability.
Sounds like a nice idea if we can better understand the benefits.
Dear libev authors and the community,
Libev has relatively weaker support on Windows than other Unix-like
platforms (Linux, BSD and macOS) due to the complexity of IOCP event
model.
library for Windows, called wepoll [1], that wraps IOCP APIs. One can
seamlessly use epoll APIs on Windows with high performance. The recent
version has fixed some LSP (Layered Service Provider) compatibility
issues and should be quite stable for normal use.
Note that with the existence of LSP dlls (e.g., Anti-virus software,
Proxifier, etc.), libuv on Windows silently falls back to a "slow
mode" that uses select() as backend. Such issue does not come with the
latest version of wepoll. Also, wepoll is significantly more
lightweight and very friendly to embed inside a project, just by
copying two source files (.c and .h).
I tried to port shadowsocks-libev [2] to MinGW using wepoll. The libev
library only needs very few changes [3] to use wepoll as backend. We
currently maintain a local fork of libev and prefer if such change
could go upstream.
Do you have any interest or opinions on integrating the wepoll library
inside libev for better Windows support?
Thanks!
[1] https://github.com/piscisaureus/wepoll
[2] https://github.com/shadowsocks/shadowsocks-libev
[3] https://github.com/shadowsocks/libev/commits/mingw
_______________________________________________
libev mailing list
http://lists.schmorp.de/mailman/listinfo/libev

...

[Marc Lehmann]

Post by Linus Yang
Libev has relatively weaker support on Windows than other Unix-like
platforms (Linux, BSD and macOS) due to the complexity of IOCP event
model.

Well, it's not weaker when it supports the same interface on windows.

The problem libev ran into was that IOCPs only work with some sockets, not
all sockets, and do not portably support event notifications. If this has
somehow been solved (or was only a problem on obsolete windows platforms)
this could be changed.

Or, rather, if the wepoll API is reasonably similar to epoll, one could
indeed recompile libev with epoll as backend, probably with miniscule
changes.

Post by Linus Yang
I tried to port shadowsocks-libev [2] to MinGW using wepoll. The libev
library only needs very few changes [3] to use wepoll as backend. We
currently maintain a local fork of libev and prefer if such change
could go upstream.
Do you have any interest or opinions on integrating the wepoll library
inside libev for better Windows support?

Since the wepoll licenses is more restrictive, it cannot be integrated,
but it should not be an issue to support wepoll as another backend,
especially since it seems to closely emulate the epoll API.

Another option would be to find out how wepoll works around the existing
problems with IOCPs only supporting a subset of sockets (if it does) and
change the windows backend in libev to use the same method, especially if
it seems simple.