search for: aio_get_direct

...f, offset, + lambda err, buf=buf: + write_completed (buf, err)) + writes = [] + + poll = select.poll () + + sfd = src.aio_get_fd () + dfd = dst.aio_get_fd () + + sevents = 0 + devents = 0 + if src.aio_get_direction () & nbd.AIO_DIRECTION_READ: + sevents += select.POLLIN + if src.aio_get_direction () & nbd.AIO_DIRECTION_WRITE: + sevents += select.POLLOUT + if dst.aio_get_direction () & nbd.AIO_DIRECTION_READ: + devents += select.POLLIN + if d...

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

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

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

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

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.

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

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

...the C<errno>. > + > +You have a choice of whether to implement one thread per nbd_handle or > +one thread shared between all handles. > + > +=item 4. Modify main loop > + > +Finally your main loop can unconditionally call > +C<nbd_aio_notify_write> when C<nbd_aio_get_direction> returns C<WRITE> > +or C<BOTH> (since the concurrent thread can always enqueue more data > +and so is always "ready to write"). Will we ever actually reach a state that is blocked on a write completion for aio_get_direction to ever even request a WRITE or BOTH? O...

...1, 0); + "aio_pwrite", (1, 0); + "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); + &...

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

...(* return a bitmask, no error possible *) and permitted_state = | Created (* can be called in the START state *) | Connecting (* can be called when connecting/handshaking *) @@ -2013,7 +2014,7 @@ Do not do anything else with the file descriptor."; "aio_get_direction", { default_call with - args = []; ret = RInt; is_locked = false; may_set_error = false; + args = []; ret = RUInt; is_locked = false; may_set_error = false; shortdesc = "return the read or write direction"; longdesc = "\ Return the current direction of t...

This works, but there's no time saving and I'm still investigating whether it does what I think it does. Nevertheless I thought I would post it because it (probably) implements the idea I had last night outlined in: https://www.redhat.com/archives/libguestfs/2019-June/msg00010.html The meat of the change is patch 4. Patch 5 is an example which I would probably fold into patch 4 for

v1: https://www.redhat.com/archives/libguestfs/2019-June/msg00014.html I pushed a few bits which are uncontroversial. The main changes since v1 are: An extra patch removes the want_to_send / check for nbd_aio_is_ready in examples/threaded-reads-and-writes.c. This logic was wrong since commit 6af72b87 as was pointed out by Eric in his review. Comments and structure of