Closed danlapid closed 1 year ago
File IO and Sockets implemented as well on top of this scheduler. See https://github.com/danlapid/cppcoro/pull/3 for files and https://github.com/danlapid/cppcoro/pull/4 for sockets
Hi, thanks a lot, this is amazing. I'll look into it as soon as possible. It would be great to finally have a Linux backend in cppcoro.
Any updates? I’d love to start getting those PRs merged As I said the design is coherent with the MacOS kqueue system so my intention is to add macOS as well Adding these 2 operating systems could truly make this library the de facto standard across all major OSs
Sorry I still did not find the time to look into this. I do my best to come back to you ASAP.
Hi danlapid, sorry for the delay. Some live events required my full attention during the last months. Now I'd have some resources. Would you be interested in following up on this? First step would be a rebase on the current main and get the CI passing. If you don't have time right now let me know, in that case I'd copy this to a new pull request owned by me (still with your commits in it) and proceed there.
@andreasbuhr Hey, I just rebased the branch and hopefully everything should just pass. I'm excited to get this merged as well as the following few branches. I have been using the full linux support added in the upcoming branches (linked above) in a few of my projects for a while and its been working amazingly. I will be away on vacation for the next 2 weeks then can continue working on this if you would be available to review my code. Until then if you feel like copying and making a new PR with any changes you see fit I would have absolutely no problems with it. Otherwise I'll fix any comments you might have when I get back. Thanks. Dan.
That's great, thanks a lot!
This is mostly based on https://github.com/lewissbaker/cppcoro/pull/64 I changed the message queue implementation from mqeueue to a simple pipe(). It's mainly just a simplification, none of the mqueue specific features were being used and the code had needless complexity. (such as dependency on libuuid). I saw the other proposals using io_uring and decided against it as it only supports new-ish kernels. Epoll would support many more kernel versions. Also, supporting kqueue for macOS would be super simple as it is almost identical to epoll in terms of usage.