[Development] Should QFileSystemWatcher be thread-safe? (Qt 5.8.0)
René J. V. Bertin
rjvbertin at gmail.com
Thu Oct 5 14:08:02 CEST 2017
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.
More information about the Development