<br><br><div class="gmail_quote">2010/2/24 Rémi Denis-Courmont <span dir="ltr"><<a href="mailto:remi@remlab.net">remi@remlab.net</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
On Wed, 24 Feb 2010 10:00:48 +0100, Jakob Leben <<a href="mailto:jakob.leben@gmail.com">jakob.leben@gmail.com</a>><br>
wrote:<br>
<div class="im">> I believe the services_discovery_t: b_loading field should be protected<br>
by<br>
> some mutex, which services_discovery_t does not have yet.<br>
<br>
</div>Why?<br>
<br>
The loading boolean has to be synchronized at a higher level. Adding a<br>
mutex here would just be a kludge to work around a would-be race condition<br>
at an higher level.<br></blockquote><div class="im"><br>Well, I assumed that reading and writing a boolean from two different threads (SD and intf) might not be safe - could result in corrupted data being read. But maybe it is safe to assume that it is always atomic.<br>
<br> <br>
> B: Or remove the b_loading field and pass the loading state as bool<br>
> through<br>
> callbacks all the way until Qt intf.<br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Yes, this does probably not need to be kept in the core.<font color="#888888"><br></font></blockquote><div><br>I stil think it is useful to have that in the core in case an interface wants to know the state even if it missed the state change event. <br>
</div></div>