Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows support #6

Open
DDRBoxman opened this issue Jul 29, 2016 · 10 comments
Open

Windows support #6

DDRBoxman opened this issue Jul 29, 2016 · 10 comments

Comments

@DDRBoxman
Copy link

No description provided.

@akashdeep-singh
Copy link

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.

@oktal
Copy link
Collaborator

oktal commented Aug 25, 2016

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.

@oktal oktal closed this as completed Jan 15, 2017
@ghost
Copy link

ghost commented Jul 19, 2020

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

@kiplingw
Copy link
Member

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.

@ghost
Copy link

ghost commented Jul 19, 2020

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

@Tachi107
Copy link
Member

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?

Tachi107 added a commit to Tachi107/pistache that referenced this issue Sep 27, 2021
related to pistacheio#41
related to pistacheio#183
related to pistacheio#760
closes     pistacheio#960
related to pistacheio#985

related to pistacheio#6
related to pistacheio#538
related to pistacheio#649
related to pistacheio#741
related to pistacheio#874

closes     pistacheio#525
Tachi107 added a commit to Tachi107/pistache that referenced this issue Sep 27, 2021
related to pistacheio#41
related to pistacheio#183
related to pistacheio#760
closes     pistacheio#960
related to pistacheio#985

related to pistacheio#6
related to pistacheio#538
related to pistacheio#649
related to pistacheio#741
related to pistacheio#874

closes     pistacheio#525
dennisjenkins75 pushed a commit that referenced this issue Sep 27, 2021
related to #41
related to #183
related to #760
closes     #960
related to #985

related to #6
related to #538
related to #649
related to #741
related to #874

closes     #525
@Samega7Cattac
Copy link

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

@Tachi107
Copy link
Member

Tachi107 commented Oct 18, 2021

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

@Samega7Cattac
Copy link

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

@Tachi107 Tachi107 reopened this May 21, 2022
@alexchandel
Copy link

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).

PetarKirov added a commit to metacraft-labs/nix-blockchain-development that referenced this issue Mar 29, 2023
* List all deps explicitly and remove `with pkgs;`
* Remove unused `gtest` and `doxygen` deps
* Enable OpenSSL support and make it optional
* Replace `with lib; with platforms;` with `lib.platforms.*`
* Use `pname` attribute instead of name
* Set platforms to Linux only, as per:
  pistacheio/pistache#6 (comment)
PetarKirov added a commit to metacraft-labs/nix-blockchain-development that referenced this issue Mar 29, 2023
* List all deps explicitly and remove `with pkgs;`
* Remove unused `gtest` and `doxygen` deps
* Enable OpenSSL support and make it optional
* Replace `with lib; with platforms;` with `lib.platforms.*`
* Use `pname` attribute instead of name
* Set platforms to Linux only, as per:
  pistacheio/pistache#6 (comment)
PetarKirov added a commit to metacraft-labs/nix-blockchain-development that referenced this issue Mar 30, 2023
* List all deps explicitly and remove `with pkgs;`
* Remove unused `gtest` and `doxygen` deps
* Enable OpenSSL support and make it optional
* Replace `with lib; with platforms;` with `lib.platforms.*`
* Use `pname` attribute instead of name
* Set platforms to Linux only, as per:
  pistacheio/pistache#6 (comment)
PetarKirov added a commit to metacraft-labs/nix-blockchain-development that referenced this issue Mar 30, 2023
* List all deps explicitly and remove `with pkgs;`
* Remove unused `gtest` and `doxygen` deps
* Enable OpenSSL support and make it optional
* Replace `with lib; with platforms;` with `lib.platforms.*`
* Use `pname` attribute instead of name
* Set platforms to Linux only, as per:
  pistacheio/pistache#6 (comment)
PetarKirov added a commit to metacraft-labs/nix-blockchain-development that referenced this issue Mar 30, 2023
* List all deps explicitly and remove `with pkgs;`
* Remove unused `gtest` and `doxygen` deps
* Enable OpenSSL support and make it optional
* Replace `with lib; with platforms;` with `lib.platforms.*`
* Use `pname` attribute instead of name
* Set platforms to Linux only, as per:
  pistacheio/pistache#6 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants