On Sat, Jun 04, 2022 at 11:16:10AM +0100, Richard W.M. Jones wrote:
On Fri, Jun 03, 2022 at 05:26:35PM -0500, Eric Blake wrote:
> After the work in the previous patch, this one is a trivial feature
> addition ;) Now you can do h.aio_pwrite(b'123', 0).
> ---
> python/handle.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/python/handle.c b/python/handle.c
> index 7f67159..8575097 100644
> --- a/python/handle.c
> +++ b/python/handle.c
> @@ -104,6 +104,11 @@ nbd_internal_py_get_aio_buffer (PyObject *buffer)
> if (PyObject_IsInstance (buffer, nbd_internal_py_get_nbd_buffer_type ()))
> return PyObject_GetAttrString(buffer, "_o");
>
> + if (PyObject_CheckBuffer (buffer)) {
> + Py_INCREF (buffer);
> + return buffer;
> + }
> +
> PyErr_SetString (PyExc_TypeError,
> "aio_buffer: expecting nbd.Buffer instance");
> return NULL;
Sorry, a late comment on this one. Should we add a test for this,
since it's plausibly something that could regress in future?
Absolutely. I'll enhance the existing python/t/5*aio_p{read_write}
tests.
Also, I just realized that our new zero-copy semantics is a potential
behavior change; previously, nbd.Buffer.from_bytearray(...) created a
copy, and thus changes via h.aio_pread did not affect the
original. Now that it is a shared buffer, aio_pread can alter the
contents of the original buffer; maybe we need to add an optional
copy=False parameter where the user can pass copy=True to force a copy
when they want to break the relation.
Similarly, nbd.Buffer.to_bytearray() has always created a copy; but we
may want to add nbd.Buffer.to_memoryview() that creates a shared view
for less copying. The fact that we have parallel aio actions means
that existing code relying on copies may break if we now reuse
existing buffers and they are now passing the same buffer
inadvertently (maybe that argues our default should be copy=True, and
new code has to opt in to copy=False for speed?)
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization:
qemu.org |
libvirt.org