Re: [Libguestfs] Libnbd asynchronous API with epoll

(Sorry for the late reply, was a bit involved in a qemu bug last week ...) On Fri, Jul 07, 2023 at 08:58:50AM +0000, Tage Johansson wrote: It's probably best to have a look at the generated code, but it works like this: - aio_notify_read is the program telling libnbd that the socket is readable. ie. The socket won't block, one byte at least is available to read. - aio_get_direction is libnbd telling the program that we are in a state where we are expecting to read or write (or either) to the socket. As an example, let's say we have just connected to the NBD server. We expect the NBD server to send a magic string, here: https://gitlab.com/nbdkit/libnbd/-/blob/20dceca48623835c3e8a195ef4135cce5... For example: $ nbdkit -s null NBDMAGICIHAVEOPT <- magic string sent by the server But in this case let's say the server is slow to send the magic string. The call to recv_into_rbuf -> h->sock->ops->recv -> recv returns EWOULDBLOCK (recv_into_rbuf returns 1). Then we stay in the same state (MAGIC.RECV_MAGIC), and return to the main program. At this point if the main program calls nbd_aio_get_direction it would return AIO_DIRECTION_READ. We are expecting to read the socket next. A write on the socket is not possible in this state (so we will not return AIO_DIRECTION_BOTH). I hope that's a bit clearer. I'm not sure about the epoll question. I haven't thought about it deeply, but it seems as if edge-triggered notification might be a problem, but you could keep track of this from the main program with an extra variable, turning edge-triggered into level-triggered. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html