On 10/11/19 8:48 AM, Richard W.M. Jones wrote:
Do we need to require the filter to be involved in the recursion?
With .open and .config, we do, because there are parameters to the
function, where the filter may change the parameter handed to the
plugin (for example, changing read-write to read-only or altering a
config key). But for other functions where there is no parameter,
we let nbdkit control the recursion (.prepare, .finalize, .close).
There is no other parameter here to be changed, so having nbdkit run
the recursion may make more sense.
Two issues I think: Do we let filters see it at all? (I did think
about leaving it out, but I included it because we cover every API.)
Do we let filters control the recursion. I think you are probably
right that it should be nbdkit doing that.
Also another hypothetical issue: filters might want to start
background threads. For filters that is complicated for two reasons:
(1) It might not be a good idea for the same reasons as plugins, and
(2) A new thread doesn't have access to the next_ops since it runs
outside a connection context.
When we wrote the cache filter, you lamented that there was no easy way
to kick off a background thread, and instead had to write a scheme where
for every client transaction, you check if the cache needs flushing, and
guarantee to make forward progress, but no faster than the client is
making requests. A true background thread does seem interesting, but
you're right that it would need some thread-safe way to have access to a
persistent copy of next_ops (while our current usage of filters has
next_ops being stack-allocated and only good for the single call).
Should there be any caveat about the threads needing to be joined no
later than .unload, so that there is no risk of the helper threads
segfaulting after the .so is unloaded?
Even with the join, nbdkit-vddk-plugin still segfaulted :-( I couldn't
work out if it was a problem with the design or the general existing
problem that nbdkit doesn't have a well-controlled shutdown path.
Possibly the latter.
Thanks for the other comments. I don't think we need this just yet so
let's leave it for another time.
Yeah, as long as this is in the archives for legacy purposes, but not
something you actually intend to apply, we can delay solving the problem
of a cleaner shutdown path until another day (not that it's ever fun
deferring technical debt, but when it is not impacting day-to-day usage,
it's hard to spend the time on it when so much else competes for
attention too).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
_______________________________________________
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs
