The waitable_queue.hpp has a bit of scope to improve
-
It is better not to expose the underlying queue through following queue functions
Queue& queue() noexcept { return queue_; } const Queue& queue() const noexcept { return queue_; }
-
As of now the epoll system calls and the queue adapter APIs can be accessed independently
Eg: try_dequeue(Output& value) removes an item but does not drain the eventfd. If a consumer calls try_dequeue() without first calling drain_notifications().., epoll_wait() may continue reporting the queue fd has still data.
The order of calling the functions shall be, somehow, enforced appropriately; like epoll_wait() followed by drain_notifications() and dequeue
The waitable_queue.hpp has a bit of scope to improve
It is better not to expose the underlying queue through following queue functions
Queue& queue() noexcept { return queue_; } const Queue& queue() const noexcept { return queue_; }As of now the epoll system calls and the queue adapter APIs can be accessed independently
Eg:
try_dequeue(Output& value)removes an item but does not drain the eventfd. If a consumer calls try_dequeue() without first calling drain_notifications().., epoll_wait() may continue reporting the queue fd has still data.The order of calling the functions shall be, somehow, enforced appropriately; like
epoll_wait()followed bydrain_notifications()anddequeue