]> git.ipfire.org Git - thirdparty/libvirt.git/commit
node_device_udev: nodeStateShutdownPrepare: Disconnect the signals explicitly
authorMarc Hartmayer <mhartmay@linux.ibm.com>
Tue, 23 Apr 2024 18:09:00 +0000 (20:09 +0200)
committerJonathon Jongsma <jjongsma@redhat.com>
Tue, 18 Jun 2024 14:00:29 +0000 (09:00 -0500)
commit2c3e4a0f6e23dbe9247d87d4bfd6951d5c9297c3
treeefa69a1001c392511a0e08948d6ec87d71bff21e
parente89d39f5b8f30f0b3284ed2bd71cee1a8a3d707d
node_device_udev: nodeStateShutdownPrepare: Disconnect the signals explicitly

The documentation of gobject signals reads:

"If you are connecting handlers to signals and using a GObject instance as your
signal handler user data, you should remember to pair calls to
g_signal_connect() with calls to g_signal_handler_disconnect() or
g_signal_handlers_disconnect_by_func(). While signal handlers are automatically
disconnected when the object emitting the signal is finalised..." [1]

This means that the signal handlers are automatically disconnected as soon as
the `priv->mdevCtlMonitors` are finalised/released by `udevEventDataDispose`.
But this also means that it's possible that new work is tried to be scheduled
for the workerpool by the `mdevctlEventHandleCallback` (main thread context)
even if the workerpool has already been stopped by `nodeStateShutdownWait`. To
fully understand this, it's important to know that the main loop of the main
thread is still running for some time even after `nodeStateShutdownPrepare` has
been called. Let's avoid this situation by explicitly disconnect the signals
during `nodeStateShutdownPrepare`, which is called in the main thread, so that
no new work is attempted to be scheduled for the worker pool.

[1] https://docs.gtk.org/gobject/signals.html#memory-management-of-signal-handlers

Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
src/node_device/node_device_udev.c