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: > 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? 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. > > I guess this is the case, but I must know or the client may hang unexpectedly. > > > Best regards, > > Tage > > > _______________________________________________ > Libguestfs mailing list > Libguestfs(a)redhat.com > https://listman.redhat.com/mailman/listinfo/libguestfs -- 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 _______________________________________________ Libguestfs mailing list Libguestfs(a)redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs