[Libguestfs] [PATCH NOT WORKING nbdkit v2 1/2] server: Add .ready_to_serve plugin method.

[Eric Blake]

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