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

[Konrad Rosenbaum]

On Saturday 30 September 2017 11:31:13 René J. V. Bertin wrote:
> Thiago Macieira wrote:
[about internal mutex]
> > You cannot, because neither the kqueue, inotify or poll backends do
> > that.
> > Those three have no mutexes at all. You have to block the event loop of
> > the thread they were created on.
> 
> That all applies to multithreaded usage, right? What happens when a change
> is signalled while an item is being added *on the same thread*? At least
> the kqueue and inotify backends are written around an API that sends
> asynchronous notifications, no?

You do know what a thread is - right? ;-)

A quick google search tells me that inotify and kqueue work by signaling 
file events through the normal mechanism of the event loop. This means the 
change is appended to the event queue and handled the next time this thread 
is idle or explicitly calls the event loop. 

It is impossible for the change event to interrupt the add method or vice 
versa. The only mechanism that can do this in the same thread is a signal 
handler.

Sorry, I'm too lazy/busy to read the source right now to make sure that no 
signal handlers are used here.

> I'm now investigating the idea of sending a signal from the dirlister
> thread, connected to a slot in the main thread with Qt::QueuedConnection
> . After some initial success I'm now getting a SEGV that I don't yet
> understand. I'm beginning to wonder if one shouldn't use a blocking
> QueuedConnection...

BlockingQueuedConnections should only be used if you really need the result, 
there is no asynchronous way of transmitting the result and you can make 
sure that there will not be a deadlock.

Apart from this I'd suspect you will still get the SEGV if you do not block 
- even if the frequency changes. This points to you using some kind of 
pointer that is not properly controlled (e.g. sending a signal to a QFSW 
that is already deleted).


	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/653b222f/attachment.sig>