[Libguestfs] [PATCH nbdkit v3 1/3] filters: Implement next_ops .reopen call.

[Eric Blake]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20190919/c39b9732/attachment.sig>