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/