[Development] Should QFileSystemWatcher be thread-safe? (Qt 5.8.0)

[René J. V. Bertin]

Konrad Rosenbaum wrote:


>> And one cannot even rely on mutexes to "fix" or prevent that?
> 
> If you use Mutexes right you can rely on them to serialize the code that
> blocks on the same Mutex, i.e. only one blocking code block is executed at
> the same time. <snip>
> Depending on hardware timings and bus congestion these
> threads may race each other.

Hmm, ok. Nothing new here in fact, but thanks :)

>> Sounds like the situation that ObjC/Apple addressed by using refcounting
> 
> If by "problem" you mean programmer stupidity (or if you prefer: naturally
> limited cognitive capacity): yes. ;-)

Heh. Let's go for the latter, with capacity determined over all brains working 
on a given project. 


> If by "acceptable" you mean "fast enough for a human being", then yes -
> QueuedConnection will do this for you reliably enough.

Careful, "for the task at hand" always implies "for a human being" (at least the 
one who defined the task) but that doesn't mean a human could resolve the 
difference between just enough and just not enough (directly, that is) ;)

> Do not make any assumptions about the order of signals or slots. Try to
> avoid the assumption that a signal only returns after the slot has been
> executed (or that it returns immediately)

That one is easy - I've never seen any user-written code that corresponds to the 
signal function, so I've always thought of it as raising a system signal.
R.