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

[Richard W.M. Jones]

On Thu, Sep 19, 2019 at 10:59:02AM -0500, Eric Blake wrote:
> > +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.

For the purposes of our use case in v2v I'm happy to set the filter
thread model to something very serialized (I think
THREAD_MODEL_SERIALIZE_ALL_REQUESTS) and add a big comment about how
we need to think about how to make it safe.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/