On 8/2/19 2:55 PM, Richard W.M. Jones wrote:

>> +++ b/plugins/sh/nbdkit-sh-plugin.pod
>> @@ -189,12 +189,11 @@ one of C<"serialize_connections">, 
>> C<"serialize_all_requests">,
>>  C<"serialize_requests">, or C<"parallel">.
>>
>>  This method is I<not> required; if omitted, then the plugin will be
>> -executed under the default sh thread model (currently
>> -C<"serialize_all_requests">, which implies this callback only makes a
>> -difference with an output of C<"serialize_connections">; look for
>> -'max_thread_model' in C<nbdkit --dump-plugin sh>).  If an error
>> -occurs, the script should output an error message and exit with status
>> -C<1>; unrecognized output is ignored.
>> +executed under the default sh thread model (either C<"parallel"> or
>> +C<"serialize_all_requests">, based on whether the platform supports
>> +L<pipe2(2)>; look for 'max_thread_model' in C<nbdkit --dump-plugin
>> +sh>).  If an error occurs, the script should output an error message
>> +and exit with status C<1>; unrecognized output is ignored.
> 
> I'm not sure we should change the default (although by all means
> change our existing shell plugins so they explicitly set the thread
> model to parallel).  One reason I think this is because we've
> advertised that people can use handles to create a temporary directory
> for saving state, and that's likely to break if the thread model
> changes.

Makes sense. So the change will be:

 - compile-time THREAD_MODEL = PARALLEL (necessary, as otherwise a
script can't request parallel)
 - if script declares .thread_model, then use that mode (any mode
possible, whereas older nbdkit silently downgrades parallel to
serialize_all_requests per the older compile-time max)
 - if script does not declare .thread_model, then use
SERIALIZE_ALL_REQUESTS (matching historical behavior)

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

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Libguestfs mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/libguestfs

Reply via email to