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

[Konrad Rosenbaum]

Hi,

On Saturday 30 September 2017 16:24:57 René J. V. Bertin wrote:
> Konrad Rosenbaum wrote:
> > Apart from this I'd suspect you will still get the SEGV if you do not
> > block - even if the frequency changes.
> 
> As in when emitting the signal too frequently from multiple threads?

No. as in how many times out of the total signals delivered it actually 
crashes. When dealing with threads and signals between them determinism 
flies out the window and the tiniest change in timing can change behavior 
radically.

> For my personal education, what happens behind the scenes when a signal is
> sent from one thread to a slot in a different thread?

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 
object. Whenever that thread's event loop is called again it will start to 
work on those events

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

Never assume order.

> being sent and such that producer and consumer don't try to modify
> (access) the queue concurrently?

Kind of.

The receiving end of the event queue is of course programmed in a thread 
safe way. And new events are usually queued towards the end of that queue.

BUT.

There are complications: for one, and this cannot be stressed enough, if you 
are dealing with threads you cannot assume anything to be completely 
deterministic or in order. Threads execute in a (seemingly) random order and 
can interrupt or race each other. For another: some events are more 
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).

So, the order of events is not 100% guaranteed. Most of the time events will 
be received and handled in the order they were sent, but there are 
exceptions.


	Konrad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170930/a4e55970/attachment.sig>