[Libguestfs] [nbdkit PATCH v2 4/6] filters: Track next handle alongside next backend

[Richard W.M. Jones]

So ... this is all complicated ...  And reverts some changes which I
found simplified things.

Stepping back here, is it the case that next-ops is really a hack, and
what filters should actually get is some kind of connection object
(let's call it that, even if it doesn't exactly correspond to "struct
connection"), on which they can make general calls to the layer
beneath.

Then we allow filters to open and close new connection objects.

How do filters get these connection objects?  I would say that unlike
next-ops, filters should not get a connection object with each
callback.  Instead in filter_open the filter should explicitly open a
new connection, and in filter_close explicitly close it.  Then
filter_pread would make a pread() call on the connection object which
the filter has saved in the filter's handle.

My questions would be, assuming a design like this magically existed:

(1) Does it solve the problem for multi-conn filter?

(2) Does it solve the problem for background threads?

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/