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

[René J. V. Bertin]

Thiago Macieira wrote:

>> >> How does QFSW handle a situation in which an already watched directory is
>> >> changed while another directory is being added? SNIP
>> > 
>> > The Darwin implementation has an internal mutex so that the dispatcher
>> > thread (I'm assuming) is able to get to the current state.
>> 
>> Can I assume that the other platforms have a similar feature that blocks
>> access to the current state while entries are being added or removed (and
>> also defers adding/removing entries while sending out change
>> notifications)?
> 
> 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?

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...

R.