Hi Bart-
are the semantics below really safe, the don't appear to? Any caller of checker_thread_running is relaying on stale information. The c->thread_running could have changed as soon as you unlock.
+static unsigned checker_thread_running(struct tur_checker_context *ct)
+{
+ unsigned thread_running;
+
+ pthread_spin_lock(&ct->hldr_lock);
+ thread_running = ct->thread_running;
+ pthread_spin_unlock(&ct->hldr_lock);
+
+ return thread_running;
+}
On Tue, Aug 16, 2016 at 3:11 PM, Bart Van Assche <bart.vanassche@xxxxxxxxxxx> 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?
Thanks,
Bart.
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
