I have found with windows at least, its instantaneous. Essentially it sets up a blocking win32 call, that gets release and emits the signal...
But it does take the event loop of the connected slots thread to be running... Scott -----Original Message----- From: interest-bounces+scott.bloom=onshorecs....@qt-project.org [mailto:interest-bounces+scott.bloom=onshorecs....@qt-project.org] On Behalf Of Andreas Pakulat Sent: Thursday, February 02, 2012 3:54 PM To: interest@qt-project.org Subject: Re: [Interest] QFileSystemWatcher malfunctioning On 02.02.12 15:23:53, Scott Aron Bloom wrote: > QFileSystemWatcher DOES operate in a separate thread 100% certainly > for windows, 99% for linux.. > > Its been a while since I looked at the insides on linux. All engines run in a separate thread and some of the engines have multiple threads themselves again (win32 and dnotify) as far as I can see from a quick grep. However these threads could be delivering their signals directly instead of delivering them through the event-queue, so there is actually a way that the blocker really blocks signals. But if the used backend is actually not triggered by the OS directly when a filesystem change happens, i.e. if it takes a few ms for the OS to notify the watcher (and thats definetly the case for the polling backend) then signal blocking will not work. Andreas _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
