[Libguestfs] nbdkit worker thread shutdown

[Nikolaus Rath]

On May 05 2022, "Richard W.M. Jones" <rjones at redhat.com> 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.



Best,
Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«