On 5/20/19 8:36 AM, Richard W.M. Jones wrote: > On Mon, May 20, 2019 at 07:30:31AM -0500, Eric Blake wrote: >> +=head2 C<.thread_model> >> + >> + int thread_model (void) >> + >> +This optional callback is called after all the configuration has been >> +passed to the plugin. It can be used to force a stricter thread model >> +based on configuration, compared to C<THREAD_MODEL>. See L</THREADS> >> +below for details. Attempts to request a looser (more parallel) model >> +are silently ignored. >> + >> +If there is an error, C<.thread_model> should call C<nbdkit_error> >> +with an error message and return C<-1>. > > Two comments: > > (1) Do we have an opportunity to change the way the thread model is > specified to allow future expansion. This might involve returning > something other than the simple int, or could be that we specify > different constants to be returned by this call. > > (Actually while making that point I think I've talked myself out of > it. But probably we should do this in the V3 API, so a note can be > added to that effect at the end of the TODO file.)
So far, we've come up with two potential models to add: VDDK's model where only the main thread is used but where parallel connections can still be made (that is slightly different than SERIALIZE_ALL_REQUESTS, not sure where it would lie conceptually between existing models), and a model that allows parallel requests from a single connection but delays responses to be in order (perhaps named SERIALIZE_RESPONSES, conceptually lies between SERIALIZE_REQUESTS and PARALLEL). We could add a utility helper function that, when given two constants, returns -1/0/1 depending on whether the first parameter is stricter/equal/looser than the second, to at least ease any out-of-order defined integer values back into a hierarchical scheme. I also wonder if we need a utility function for a plugin to learn which threading model ACTUALLY got selected, usable during .open or later (if the plugin supports PARALLEL but is run with a filter that forces SERIALIZE_ALL_REQUESTS, the plugin might be able to optimize out the use of a mutex). > > (2) Shouldn't it be an error if the thread model returns a more > parallel thread model than the constant? I thought about that, but my initial idea was to instead just declare that attempts at a more parallel model are just silently ignored (with at most a debug message visible during -fv). > > Anyway patch series generally looks fine to me. > > Rich. > -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
