Hello, As part of the Rust bindings for Libnbd, I try to integrate the asynchronous (aio_*) functions with Tokio <https://docs.rs/tokio/latest/tokio/>, the most used asynchronous runtime in Rust. However, in its eventloop, Tokio uses epoll(7) instead of poll(2) (which is used internally in Libnbd). The difference is that poll(2) uses level-triggered notifications as aposed to epoll(7) which uses edge-triggered notifications. In short, the difference is that if one would wait for a file discriptor to be readable, epoll would block until the file descriptor changes from not readable to readable. So if the file descriptor is already readable then epoll would block until it becomes unreadable and readable again. I am not sure how to integrate Libnbd into an edge-triggered system. The following questions arises: - After calling aio_get_direction(3), can I know that reading/writing would actually block? - After calling for example aio_notify_read(3), can I know that the next reading from the file descriptor would block? If the answers to both of these questions are no, the only solution I can think of is to call poll(2) with a timeout of 0 as a non blocking check if the file descriptor is ready. Only if the call to poll(2) fails, I would use the epoll-driven eventloop to wait for changes. What do you think about this? Do you have an easier solution to integrate Libnbd with an edge-triggered eventloop? Best regards, Tage -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://listman.redhat.com/archives/libguestfs/attachments/20230705/a653e81a/attachment.htm>
On Wed, Jul 5, 2023 at 3:38?PM Tage Johansson <tage.j.lists at posteo.net> wrote:> As part of the Rust bindings for Libnbd, I try to integrate the > asynchronous (aio_*) functions with Tokio > <https://docs.rs/tokio/latest/tokio/>, the most used asynchronous runtime > in Rust. However, in its eventloop, Tokio uses epoll(7) instead of poll(2) > (which is used internally in Libnbd). The difference is that poll(2) uses > level-triggered notifications as aposed to epoll(7) which uses > edge-triggered notifications. >According to epoll(7) section "Level-triggered and edge-triggered" says: By contrast, when used as a level-triggered interface (the default, when EPOLLET is not specified), epoll is simply a faster poll(2), and can be used wherever the latter is used since it shares the same seman? tics. So you should not have any issue using epoll instead of poll.> - After calling aio_get_direction(3), can I know that reading/writing > would actually block? >No, this is just the events that libnbd wants to get. - After calling for example aio_notify_read(3), can I know that the next> reading from the file descriptor would block? >No, you have to call again aio_get_direction() and poll again until the event happens. Nir -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://listman.redhat.com/archives/libguestfs/attachments/20230706/b01f8b96/attachment.htm>