Re: [Libguestfs] [nbdkit PATCH v2 5/5] RFC: python: Track and cache per-connection state in C struct
On 04/19/2018 12:40 PM, Richard W.M. Jones wrote:
On Wed, Apr 11, 2018 at 12:03:42AM -0500, Eric Blake wrote:
> Now that we have FUA support, the C code can call can_fua as
> frequently as on every write. If the python script has a
> can_fua, we can avoid doubling the calls into python by
> caching the per-connection results, done by wrapping the
> python handle in a C struct.
>
> This commit is marked RFC because it might be nicer if the C
> code implemented the caching for ALL plugins (TODO already
> mentions that).
It's not very clear to me (and this applies to all can_* functions) if
it's OK to call them only once per connection.
I can't think of any argument against that. Is there a potential
meaning for a plugin to "change its mind" during a connection?
Not with our current documentation in nbdkit-plugin.pod:
=item C<.can_write>, C<.get_size> and other option
negotiation callbacks
These are called during option negotiation with the client, but before
any data is served. These callbacks may return different values
across different C<.open> calls, but within a single connection, must
always return the same value; other code in nbdkit may cache the
per-connection value returned rather than using the callback a second
time.
And not really in the NBD protocol, either: the option negotiation
callbacks are called up front during handshake time, and determine the
flags advertised to the client; there is no support in the NBD protocol
for runtime changing of the advertised flags.
I suppose if the NBD protocol ever DOES add a way to change negotiation
features at runtime (an obvious one being the proposal to add an
NBD_CMD_RESIZE that affects .get_size; but also perhaps allowing
.can_write to toggle between on or off according to other situations),
then we'd need to allow those bits of information to change according to
callbacks added in response to the NBD protocol. But again, that would
be an addition to the API of the plugin contract, so a new enough plugin
that wants runtime changing has to opt in to that, which means our
existing semantics of per-connection caching (if we implement it) for
all existing can_FOO functions would still work as-is on older plugins.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 619 bytes)