On 08/17/2016 07:44 AM, Hannes Reinecke wrote:
On 08/16/2016 10:11 PM, Bart Van Assche wrote:
On 08/15/2016 11:31 PM, Hannes Reinecke wrote:
Makes one wonder: what happens to the waitevent threads?
We won't be waiting for them after applying this patch, right?
So why did we ever had this busy loop here?
Ben?
(And while we're at the subject: can't we drop the waitevent threads
altogether? We're listening to uevents nowadays, so we should be
notified if something happened to the device-mapper tables. Which should
make the waitevent threads unnecessary, right?)
Hello Hannes,
Maybe this is not what you had in mind, but would you agree with the
attached two patches?
Well, yes, sort of.
However, it still would mean that the main multipath daemon thread might
terminate before the event threads have completed, though.
Not sure if it matters, just wanted to bring is up.
Hello Hannes,
I think that for the tur checker the libcheck_free() function should
wait until the tur thread has finished. multipathd calls
remove_maps_and_stop_waiters() during shutdown and that function calls
libcheck_free() for all checkers that were loaded.
Regarding the waiter threads: stop_waiter_thread() is called by
_remove_map() so the waiter threads are also stopped during multipathd
shutdown.
Bart.
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel