Libguestfs - Jul 2023 - Libnbd asynchronous API with epoll

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>

On 7/6/2023 7:06 PM, Nir Soffer wrote:
>
> - 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.
>
Well, what I mean is:

After calling aio_notify_read, if aio_get_direction returns 
AIO_DIRECTION_READ or AIO_DIRECTION_BOTH, can I know that the reading on 
the file descriptor actually blocked? Or might there be cases when 
aio_notify_read returns and the next direction includes a read and there 
is still more data to read on the file descriptor?


I guess this is the case, but I must know or the client may hang 
unexpectedly.


Best regards,

Tage

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://listman.redhat.com/archives/libguestfs/attachments/20230707/bdfb0fa2/attachment.htm>