On 9/19/19 10:26 AM, Richard W.M. Jones wrote:
This is intended for use by the forthcoming retry filter to close
and
reopen the backend chain. It is handled entirely by server/backend.c
as no cooperation is needed with the plugin.
Note the explicit readonly parameter: An alternative would be to store
the previous readonly setting in the b_conn_handle struct. However
passing it explicitly allows the retry filter to retry as readonly,
which might be useful. This design does however require any filter
which might call .reopen to save the original readonly parameter from
the .open call.
---
include/nbdkit-filter.h | 6 ++++++
server/backend.c | 12 ++++++++++++
server/filters.c | 8 ++++++++
server/internal.h | 4 ++++
4 files changed, 30 insertions(+)
I made comments on v2 that still apply here (crossed emails again).
Another one I just thought of:
+int
+backend_reopen (struct backend *b, struct connection *conn, int readonly)
+{
+ struct b_conn_handle *h = &conn->handles[b->i];
+
+ debug ("%s: reopen", b->name);
+
+ if (h->handle != NULL)
+ backend_close (b, conn);
+ return backend_open (b, conn, readonly);
Do we want to grab a resource lock at this point? Should we be trying
hard to prevent further client calls from going to the retry filter
while the retry filter is reopening the real plugin? Or do those locks
belong in the retry filter itself? If nothing else, we probably want
some sort of locking to ensure that two threads are not trying reopen at
the same time.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization:
qemu.org |
libvirt.org