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

[René J. V. Bertin]

Konrad Rosenbaum wrote:

Hi,

I see I'm not the only one accepting the fact that when dealing with event-
driven GUIs having a human-in-the-loop one rather quickly reaches a stage where 
it becomes hard to guarantee anything (with all that implies for writing code 
that handles unforeseen situations *gracefully*).

> crashes. When dealing with threads and signals between them determinism
> flies out the window and the tiniest change in timing can change behavior
> radically.

No kidding (I'm used to working on/with older hardware or simply stressing it 
and seeing all kinds of things no one else can apparently reproduce.)

As I said, the crashes I saw were not to do inappropriate signal/slot 
programming but to me not understanding something in "wildcard" capturing for 
lambdas. IOW, the crash frequency has been 0 ever since I fixed that (the 
capture, not my understanding :))

> Whenever a QueuedConnection triggers the sending object generates an event
> and delivers it to the event queue of the thread that owns the target slot's

So the sending object knows that the nature of each connection to it?

>> Can I assume
>> there's some kind of fifo that ensures signals are delivered in order of
> 
> Never assume order.

Ok. From your other reactions I infer there is something like a mostly-fifo with 
a mutex that protects pushing and popping :)

> deterministic or in order. Threads execute in a (seemingly) random order and
> can interrupt or race each other.

And one cannot even rely on mutexes to "fix" or prevent that?

> important or less important than others - e.g. the deleteLater event is
> normally only handled at the top level of the event loop to prevent crashes
> caused by less then absolutely ingenious programmers using QueuedConnection,
> deleteLater and QEventLoop (that fact saved my bacon a few times).

Sounds like the situation that ObjC/Apple addressed by using refcounting instead 
of direct deletion.

Anyway, order isn't crucial in the particular application I'm working on here. 
The only thing that matters is that signals are delivered in an acceptable time-
frame after having been sent. And that should be the case (my initial reason for 
getting involved with this was to keep the main event loop from being blocked).

R.