search for: serialize_all_requests

...ool, but plugins can opt for more or less concurrency by adjusting the thread model: http://libguestfs.org/nbdkit-plugin.3.html#Threads The file plugin uses PARALLEL: $ nbdkit file --dump-plugin | grep thread max_thread_model=parallel thread_model=parallel The VDDK plugin currently uses SERIALIZE_ALL_REQUESTS: $ nbdkit vddk --dump-plugin | grep thread max_thread_model=serialize_all_requests thread_model=serialize_all_requests The proposal is to use SERIALIZE_REQUESTS, with an extra mutex added by the plugin around VixDiskLib_Open and _Close calls. PARALLEL is not possible. > This is kind of...

On Fri, Aug 02, 2019 at 02:26:16PM -0500, Eric Blake wrote: > When we first created the sh plugin, we copied the thread model used > in most other language bindings of SERIALIZE_ALL_REQUESTS, because it > was easier to reason about and there was no way for a script to > override our choice. However, we've since added support for scripts > to request a tighter model when needed, and we've also just fixed > remaining bugs about fds inadvertently leaked into the shell...

...tation, we must do all open/close calls from a single - * thread. This is a huge pain. +/* The rules on threads and VDDK are here: + * https://code.vmware.com/docs/11750/virtual-disk-development-kit-programming-guide/GUID-6BE903E8-DC70-46D9-98E4-E34A2002C2AD.html + * + * Before nbdkit 1.22 we used SERIALIZE_ALL_REQUESTS. Since nbdkit + * 1.22 we changed this to SERIALIZE_REQUESTS and added a mutex around + * calls to VixDiskLib_Open and VixDiskLib_Close. This is not quite + * within the letter of the rules, but is within the spirit. */ -#define THREAD_MODEL NBDKIT_THREAD_MODEL_SERIALIZE_ALL_REQUESTS +#define T...

...ose calls from a single > - * thread. This is a huge pain. > +/* The rules on threads and VDDK are here: > + * > https://code.vmware.com/docs/11750/virtual-disk-development-kit-programming-guide/GUID-6BE903E8-DC70-46D9-98E4-E34A2002C2AD.html > + * > + * Before nbdkit 1.22 we used SERIALIZE_ALL_REQUESTS. Since nbdkit > + * 1.22 we changed this to SERIALIZE_REQUESTS and added a mutex around > + * calls to VixDiskLib_Open and VixDiskLib_Close. This is not quite > + * within the letter of the rules, but is within the spirit. > The document is very clear about using the same thread for...

...strategic sleeps. In fact, I have to tweak this commit message: you CAN'T observe this one with the sh plugin unless you recompile it to use #define THREAD_MODEL NBDKIT_THREAD_MODEL_SERIALIZE_REQUESTS, as well as introducing the timing hacks mentioned above (that's because with our current SERIALIZE_ALL_REQUESTS, there is never more than one thread in filter/plugin code at a time). But it does raise an interesting point - if we hit platforms that are unable to support atomic CLOEXEC, one possibility is a patch that forces SERIALIZE_ALL_REQUESTS as the maximum parallelism allowed on that platform (while re...

...gt; > http://libguestfs.org/nbdkit-plugin.3.html#Threads > > > > The file plugin uses PARALLEL: > > > > $ nbdkit file --dump-plugin | grep thread > > max_thread_model=parallel > > thread_model=parallel > > > > The VDDK plugin currently uses SERIALIZE_ALL_REQUESTS: > > > > $ nbdkit vddk --dump-plugin | grep thread > > max_thread_model=serialize_all_requests > > thread_model=serialize_all_requests > > > > The proposal is to use SERIALIZE_REQUESTS, with an extra mutex added > > by the plugin around VixDiskLib_Ope...

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&qu...

When we first created the sh plugin, we copied the thread model used in most other language bindings of SERIALIZE_ALL_REQUESTS, because it was easier to reason about and there was no way for a script to override our choice. However, we've since added support for scripts to request a tighter model when needed, and we've also just fixed remaining bugs about fds inadvertently leaked into the shell script (at least, w...

...o tweak this commit message: you CAN'T observe this one >> with the sh plugin unless you recompile it to use #define THREAD_MODEL >> NBDKIT_THREAD_MODEL_SERIALIZE_REQUESTS, as well as introducing the >> timing hacks mentioned above (that's because with our current >> SERIALIZE_ALL_REQUESTS, there is never more than one thread in >> filter/plugin code at a time). > > The current nbdkit-sh-plugin is only SERIALIZE_ALL_REQUESTS in order > to make writing the shell scripts a bit more sane. I believe it could > be fully PARALLEL. Other than the fact that it uses pipe(...

...plugin.3.html#Threads > > > > > > The file plugin uses PARALLEL: > > > > > > $ nbdkit file --dump-plugin | grep thread > > > max_thread_model=parallel > > > thread_model=parallel > > > > > > The VDDK plugin currently uses SERIALIZE_ALL_REQUESTS: > > > > > > $ nbdkit vddk --dump-plugin | grep thread > > > max_thread_model=serialize_all_requests > > > thread_model=serialize_all_requests > > > > > > The proposal is to use SERIALIZE_REQUESTS, with an extra mutex added > > >...

...As this version is a little old I'll do an update and >> see if newer versions support it. > > I'm on hrev53313+1 which also doesn't appear to have SOCK_CLOEXEC (nor > does it have accept4). Ouch. Then I'm seriously thinking of a followup patch which either forces SERIALIZE_ALL_REQUESTS on all plugins when SOCK_CLOEXEC is missing, or which adds a bool to the plugin interface that the plugin sets to true if it does not fork (default to false), and where we force SERIALIZE_ALL_REQUESTS plugins which have not set it to true (most of our in-tree plugins can set the bool to true). --...

...urrency by adjusting the thread model: > > http://libguestfs.org/nbdkit-plugin.3.html#Threads > > The file plugin uses PARALLEL: > > $ nbdkit file --dump-plugin | grep thread > max_thread_model=parallel > thread_model=parallel > > The VDDK plugin currently uses SERIALIZE_ALL_REQUESTS: > > $ nbdkit vddk --dump-plugin | grep thread > max_thread_model=serialize_all_requests > thread_model=serialize_all_requests > > The proposal is to use SERIALIZE_REQUESTS, with an extra mutex added > by the plugin around VixDiskLib_Open and _Close calls. I'm not su...

...n fact, I have to tweak this commit message: you CAN'T observe this one > with the sh plugin unless you recompile it to use #define THREAD_MODEL > NBDKIT_THREAD_MODEL_SERIALIZE_REQUESTS, as well as introducing the > timing hacks mentioned above (that's because with our current > SERIALIZE_ALL_REQUESTS, there is never more than one thread in > filter/plugin code at a time). The current nbdkit-sh-plugin is only SERIALIZE_ALL_REQUESTS in order to make writing the shell scripts a bit more sane. I believe it could be fully PARALLEL. (As an aside: Ideally in future we'll allow the thread mod...

...tter than what we are doing at the moment. Not sure at present if this will be easy or will add a lot of complexity. Read on ... I found through experimentation that it is possible to open multiple VDDK handles pointing to the same disk. This would allow us to use SERIALIZE_REQUESTS (instead of SERIALIZE_ALL_REQUESTS) and have overlapping calls through different handles all pointing back to the same server/disk. We should have to change all open/close calls to make the request through a single background thread - see document above for why. Adding a background thread and all the RPC needed to marshall these c...

This is a major rewrite compared to my v1 series, where I've tried a lot harder to ensure that we still accommodate building on Haiku (although I have not actually yet fired up a Haiku VM to try it for myself). I also managed to make the sh plugin fully parallel, on capable platforms. See also my question on patch 10 on whether I've picked the best naming convention. Eric Blake (17):

I'm fairly sure that these bugs which appear in the Python plugin: https://bugzilla.redhat.com/show_bug.cgi?id=1566516 https://bugzilla.redhat.com/show_bug.cgi?id=1566522 are really bugs in the SERIALIZE_ALL_REQUESTS thread model. See the first patch for the full explanation. The second patch is a fix for a race condition which is probably nudged into being by the first patch. Now this all works, EXCEPT it quite reliably breaks either the NBD plugin or ‘tests/test-parallel-nbd.sh’. I have no idea why becaus...

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

...e 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 f...

On Wed, Jul 31, 2019 at 04:31:32PM -0500, Eric Blake wrote: > This reverts commit 25206df20275aeff346d9b86adf5e9be99cc9e43. > > An upcoming patch wants to ensure no leaked fds from the server to a > child process. POSIX has required O_CLOEXEC since 2008, and although > current POSIX doesn't yet specify full atomic interfaces everywhere > such as SOCK_CLOEXEC, it does have

Rich pointed out that making thread_model dynamic even for plugins makes some sense, so here is the code for doing it for 'sh'. I'm less confident on how to do it for OCaml and Rust (not to mention that those allow the plugin to already compile in their model, rather than the language binding glue forcing a model). The other languages (lua, perl, python, ruby) still need to be