Windows support about pistache HOT 10 OPEN

Thanks @FastInvite2k2. While I respect your decision to still use Windows, you must appreciate that the majority of the people using Pistache have long since moved past it. We get that many people still rationalize using because it is still popular.

However, it is a very poorly written operating system and not particularly attractive to develop on for the best engineers that I've encountered throughout my life. There is no system package manager, no file hierarchy standard, incapable of being publicly audited, endless security problems, and other costly liabilities. It adds nothing of unique value to the world today.

Just my two cents, but I would encourage you to consider upgrading from legacy systems to a GNU system of your choice. The alternative is that you wait for the triage of scarce community resources against an archaic OS that probably should have been abandoned in the 90s.

from pistache.

@kiplingw Stop trolling in GitHub issues. It is the wrong place. We are professionals, not children.

from pistache.

Hello,

I understand your frustration. Currently, Pistache does not compile on windows as it's using Unix and Linux-specific primitives like epoll(). While it would be pretty easy to create an abstraction for sockets, the story is not the same for epoll(). Pistache uses a Reactor design-pattern for I/O control based on epoll(). The goal of this pattern is to get notified when an event becomes ready on a particular file descriptor (we can call it the ready-ness model).

However, Windows uses a slightly different approach with IOCP where you get notified when an operation completed on a particular port. For example, on Linux, you first register your socket fd on epoll and then get notified when there is data to read. You then read() the data. On Windows, you first read() and then you get notified when the read completed. This is the completion model. Completion model can be implemented in terms of ready-ness model. However, ready-ness model can not be implemented in terms of completion model. This is why frameworks like boost::asio directly use the completion model.

Since Pistache is currently using the ready-ness model, it is not that easy to port the Reactor sub-system with IOCP on Windows, it would take a different approach. However, if people are interested in trying to figure out something, I would be glad to help and guide through the code.

from pistache.

I've been looking for s REST micro-framework for C++ on Windows for a few days. Bummer this one doesn't cut it yet.

from pistache.

Why not create a select() based reactor? It is not efficient but it would make the library usable for Windows.

from pistache.

Could the new I/O Ring Windows API help here?
It is similar to Linux's io_uring, and while Pistache uses epoll the two APIs shouldn't be completely different (I may be completely wrong, I've just started looking into this).
@oktal, what do you think about this?

from pistache.

Isn't it possible to make it usable at least on MSYS2 environment?

from pistache.

I know it works in WSL, but I never tried compiling it with MSYS2. Have you tried compiling the library?

from pistache.

I tried and it's missing a bunch of headers, tried to fix it but I ended up deeper and deeper with more and more stuff to fix

from pistache.

However, ready-ness model can not be implemented in terms of completion model.

This is false, it's just more complex. But Rust's async library (tokio-rs) wraps IOCP for its reactor, which uses a "readyness" model internally (mio).

from pistache.