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

> 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?