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

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/