search

pistacheio / pistache

A high-performance REST toolkit written in C++
https://pistacheio.github.io/pistache/
Apache License 2.0
3.2k stars 700 forks source link

Move code to cross-platform C++... #975

Open FredM67 opened 3 years ago

FredM67 commented 3 years ago

The doc says "It is entirely written in pure-C++17"... why is the code not 100% pure C++17 ? event_fd is linux specific for example. That could be replaced with condition variable and Co.

With 100% pure C++17, the code could be fully cross-platform and so will gain support for Windows and MacOs.

kiplingw commented 3 years ago

Thanks @FredM67. If you'd like to submit a PR and with corresponding unit tests, one of us would be happy to take a look.

FredM67 commented 3 years ago

Well, first I've to find time for that ! I'll try...

Tachi107 commented 3 years ago

Hi @FredM67, as you probably know C++ doesn't have networking support, so it is impossible to implement a REST framework without using system-specific APIs. Pistache is designed around Linux's epoll, and other platforms don't have a similar API (see details in https://github.com/pistacheio/pistache/issues/6#issuecomment-242398225). It may be possible to switch to io_uring a newer Linux API that seems to have a Windows counterpart, and should also be faster.

Edit: I agree that some parts could be refactored to use std alternatives

Edit 2: Disclaimer: I don't know almost anything about async IO and C++ networking, I may be completely wrong. If you think you have a solution, please tell us :)

FredM67 commented 3 years ago

Oh yes sorry, I did forget the network stuff.... Indeed, all the thread sync, notifications, ... could be achieved with cross-platform C++ with the STL.

TabrynP commented 2 years ago

Hello! I don't have a ton of time on my hands, but assuming time is not of the essence I think I might be able to assist. I have a good deal of experience in Boost Asio as well as the asynchronous programming features of the standard library (std::async, std::promise/std::future, etc), Linux socket networking, and user space networking.

First question about a potential cross-platform network implementation: is the Reactor pattern a strict requirement? If yes, I would be curious to know why! Not planning on pushing back, just for curiosity's sake.

kiplingw commented 2 years ago

@TabrynP, removing the reactor pattern would be a major pain. It's the core design pattern basically everything important is built around.

Having said that, the reactor pattern itself doesn't require the BSD sockets interface we are using, per se. But if the network API itself was replaced, it would make sense to do so with the upcoming STL networking API as the way to go. It's based on the Boost Asio library's design.

TabrynP commented 2 years ago

@kiplingw Makes sense to me! It seems like the latest versions of both Boost and non-boost Asio implement the new networking API. Are either of those libraries acceptable dependencies? That would be the shortest path.

Re-implementing the existing networking features according to the standard API and adding cross-platform functionality along the way is also reasonable, but it would take considerably longer.

Tachi107 commented 2 years ago

I originally chose Pistache mainly because of its performance, but I don't know if Asio will be able to deliver the same speed; it should be important to take a look at some benchmarks, maybe also taking a look at Boost.Beast

kiplingw commented 2 years ago

I think adding a new dependency isn't really the issue (for me at least). That's something the package manager solves when the user pulls the library. It's a question of which dependency. I think the best thing to do is wait until the STL standardizes the networking API and implementations become ubiquitous.