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/ On Thu, May 31, 2018 at 8:44 AM, Linus Yang <[email protected]> wrote: > > 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 > > On Thu, May 31, 2018 at 8:39 PM, Chris Brody <[email protected]> > wrote: > > 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. > > > > On May 31, 2018 7:55 AM, "Linus Yang" <[email protected]> wrote: > > > > 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 > > > > _______________________________________________ > > libev mailing list > > [email protected] > > http://lists.schmorp.de/mailman/listinfo/libev > > > > >
_______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/mailman/listinfo/libev
