[Libguestfs] [nbdkit PATCH 2/3] server: Expose final thread_model to filter's .get_ready

[Eric Blake]

On 8/10/20 8:45 AM, Richard W.M. Jones wrote:

>> Oh, one other oddity: I've been thinking about adding a fifth
>> threading model (SERIALIZE_RETIREMENT), where commands can be
>> serviced in parallel on a single connection, but replies to the
>> client are reordered to match the client's submission order; for
>> filters, exposing a new threading model through .get_ready is not a
>> problem (all filters are in tree), but for plugins, such an action
>> would mean that the plugin may get a thread model selected at
>> runtime that was unknown to the plugin at compile time.  If the
>> plugin is trying to make decisions on how much internal locking it
>> needs to create, those decisions become more awkward when having to
>> deal with an unknown thread model (then again, robust code should
>> always be written to assume as much parallelism as possible, and
>> only optimize for less locking on known models that are more
>> serialized).
> 
> Sure; are there really clients which have this restriction?

I'm not sure if there are actual clients that depend on this, but it's 
easy enough with libnbd to write a client that can batch up multiple AIO 
requests, and still be confused if the replies aren't in the same order 
as what got sent.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org