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