search for: aio_notify_read

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_...

(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 ret...

...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/lib...

...the rather thin manual page for > set_opt_mode how it works. docs/libnbd.pod is a good place for a > broader description of how it works. Yes, good idea. State-wise, the existing flow was: Created - Progress only by command issue - namely one of nbd_connect_* Connecting - Progress by aio_notify_read/aio_notify_write (as driven by aio_poll), and progresses through socket establishment, magic numbers, and handshaking Loop of: Ready - Progress by command issue (I/O commands) or aio_notify_read Processing - Progress by aio_notify_read/aio_notify_write, commands are queued rather...

...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 wo...

...+ for (fd, revents) in poll.poll (): + # The direction of each handle can change since we + # slept in the select. + if fd == sfd and revents & select.POLLIN and \ + src.aio_get_direction () & nbd.AIO_DIRECTION_READ: + src.aio_notify_read () + elif fd == sfd and revents & select.POLLOUT and \ + src.aio_get_direction () & nbd.AIO_DIRECTION_WRITE: + src.aio_notify_write () + elif fd == dfd and revents & select.POLLIN and \ + dst.aio_get_direction () &...

This is the bare minimum needed to allow the user to take control over the rest of option negotiating. This patch adds several new API: nbd_set_opt_mode() - called during Created to enable the new mode nbd_get_opt_mode() - query whether opt mode is enabled nbd_opt_go() - used in Negotiating state to attempt to use export nbd_opt_abort() - used in Negotiating state to skip Connected state

v1 was here: https://www.redhat.com/archives/libguestfs/2019-August/msg00103.html In v2 I've made several changes: - Fix Python callbacks so if they don't return something which is int-like, we assume they mean to return 0. - Add nbd.Buffer free() method. Read commit message in patch 2 to see what this is about. - Fixed the asynch copy test to deal with the unbelievably

Basically the same as this patch series, but for Python: https://www.redhat.com/archives/libguestfs/2019-August/msg00235.html plus adding the 590 asynch test at the end. Rich.

...+ "aio_disconnect", (1, 0); + "aio_flush", (1, 0); + "aio_trim", (1, 0); + "aio_cache", (1, 0); + "aio_zero", (1, 0); + "aio_block_status", (1, 0); + "aio_get_fd", (1, 0); + "aio_get_direction", (1, 0); + "aio_notify_read", (1, 0); + "aio_notify_write", (1, 0); + "aio_is_created", (1, 0); + "aio_is_connecting", (1, 0); + "aio_is_ready", (1, 0); + "aio_is_processing", (1, 0); + "aio_is_dead", (1, 0); + "aio_is_closed", (1, 0); + "...

This doesn't include Eric's new APIs, but if you push those then I can rebase this one on top. Rich.

This doesn't yet work. However it does make me more convinced than ever that we really need to sort out persistent buffer lifetimes in the library (similar to what we did for closures). Rich.

This is a combination of these two earlier series: https://www.redhat.com/archives/libguestfs/2019-August/msg00235.html https://www.redhat.com/archives/libguestfs/2019-August/msg00240.html plus changes to allow .callback = NULL / .free != NULL, and to reduce the complexity of freeing callbacks. Although it's rather long there's nothing complex here. We might consider squashing some