You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I don't think there is any documentation regarding the use of multiple threads and load balancing.
Windows IOCP documentation is very explicit about how it interacts with multiple threads. https://man7.org/linux/man-pages/man7/epoll.7.html has If multiple threads (or processes, if child processes have inherited the epoll file descriptor across fork(2)) are blocked in epoll_wait(2) waiting on the same epoll file descriptor and a file descriptor in the interest list that is marked for edge-triggered (EPOLLET) notification becomes ready, just one of the threads (or processes) is awoken from epoll_wait(2). This provides a useful optimization for avoiding "thundering herd" wake-ups in some scenarios.. But I don't think there is anything similar about io_uring.
When somebody tried to implement an io_uring backend for ASIO (which may well be the standard networking API in C++23) this is what he had to say (https://github.com/PodnimatelPingvinov/asio/tree/io-uring#concurrency): you can't concurrently make ... 2 reads from CQ. You can concurrently wait for completions in CQ (using io_uring_wait_cqe in multiple threads), but in such situation all waiting threads will be woken up when completion event become available. This is not what you want, that's why only one thread should wait for completions in the same time. Therefore I use io_uring in the same manner as reactor works, via existing scheduler. and then goes to complain about the resulting performance. He basically takes the data from that nice shared memory CQ and copies it into an user-space queue. I expect the basis of his implementation to be wrong. But I can't really tell him or a great alternative.
Basically io_uring looks great avoiding system calls and data copying, but... who takes care of the load balancing?
The text was updated successfully, but these errors were encountered:
I don't think there is any documentation regarding the use of multiple threads and load balancing.
Windows IOCP documentation is very explicit about how it interacts with multiple threads. https://man7.org/linux/man-pages/man7/epoll.7.html has
If multiple threads (or processes, if child processes have inherited the epoll file descriptor across fork(2)) are blocked in epoll_wait(2) waiting on the same epoll file descriptor and a file descriptor in the interest list that is marked for edge-triggered (EPOLLET) notification becomes ready, just one of the threads (or processes) is awoken from epoll_wait(2). This provides a useful optimization for avoiding "thundering herd" wake-ups in some scenarios.
. But I don't think there is anything similar about io_uring.When somebody tried to implement an io_uring backend for ASIO (which may well be the standard networking API in C++23) this is what he had to say (https://github.com/PodnimatelPingvinov/asio/tree/io-uring#concurrency):
you can't concurrently make ... 2 reads from CQ. You can concurrently wait for completions in CQ (using io_uring_wait_cqe in multiple threads), but in such situation all waiting threads will be woken up when completion event become available. This is not what you want, that's why only one thread should wait for completions in the same time. Therefore I use io_uring in the same manner as reactor works, via existing scheduler.
and then goes to complain about the resulting performance. He basically takes the data from that nice shared memory CQ and copies it into an user-space queue. I expect the basis of his implementation to be wrong. But I can't really tell him or a great alternative.Basically io_uring looks great avoiding system calls and data copying, but... who takes care of the load balancing?
The text was updated successfully, but these errors were encountered: