Re: [Libguestfs] nbdkit worker thread shutdown

On May 05 2022, "Richard W.M. Jones" <rjones(a)redhat.com&gt; wrote: > On Thu, May 05, 2022 at 08:59:56AM +0100, Nikolaus Rath wrote: >> Hello, >> >> When nbdkit calls a plugin's unload() method, is it guaranteed that all >> pending requests have been handled (and all worker threads exited)? >> >> (I would have expected this to be the case, but I'm getting errors from >> threads accessing data that my unload() handler frees, so I wanted to >> confirm my assumption). > > .unload is literally called just before dlclose (see > server/backend.c:backend_unload) so if a thread in nbdkit was to > access something in your plugin after .unload then that would be quite > a serious bug in nbdkit. It would be bound to crash because the code > and data has been unloaded from the process. This implies too that > all connections would have been closed already. > > Normally the server has no view into your plugin except through the > pointers in the plugin structure, and it shouldn't be using those > after .unload. Can you give us some clue as to what exactly nbdkit is > accessing in your plugin? It *looks like* one of the nbdkit-started worker threads is still executing the plugin's read() handler at the time that a different thread is executing the plugin's unload() handler (background: https://github.com/archiecobbs/s3backer/issues/180). However, this may not actually be the case. I wanted to confirm that this is not expected behavior before diving into this deeply. Now that I know that it shouldn't happen (this is what you're saying, right?), I'll investigate in more detail and hopefully either find a different explanation for the symptoms or provide a proper nbdkit bug report.