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. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
