Curious about the EventLoop updates

Crystal Contrib
1

I saw this PR come up Add EventLoop#run(blocking) and EventLoop#interrupt by ysbaddaden · Pull Request #14568 · crystal-lang/crystal · GitHub and it reminded me about this PR Linux's io_uring IO interface (2x performance vs libevent) by lbguilherme · Pull Request #10768 · crystal-lang/crystal · GitHub

I was curious if all of these libevent refactors would have any affect on Crystal being about to use the io_uring stuff in the future, or would we end up having to refactor everything again to support that? Is this something being considered in these refactors? Or is it even worth considering?

2

Related: rfcs/text/0007-event_loop-refactor.md at rfc/0005 · crystal-lang/rfcs · GitHub

1 Like
3

This PR is to enable more scenarios to implement RFC #0007: Event loop refactor by straight-shoota · Pull Request #7 · crystal-lang/rfcs · GitHub (wip at GitHub - ysbaddaden/execution_context).

We plan to fully refactor EventLoop over the coming months, with a stable interface & behavior, in order and to talk directly to kqueue, epoll and io_uring of course. See RFC #0007: Event loop refactor by straight-shoota · Pull Request #7 · crystal-lang/rfcs · GitHub

4 Likes
4

ooo nice! That’s some exciting stuff. Great work on that @ysbaddaden :raised_hands:

5

I need to add that this is part of the effort of 84codes helping Crystal to iron multi-threading support.

7 Likes