Den mån 4 mars 2019 16:34Sylvain Pointeau <sylvain.point...@gmail.com> skrev:
> On Sun, Mar 3, 2019 at 10:56 PM Elvis Stansvik <elvst...@gmail.com> wrote: > >> There should be no such delay in QFutureWatcher. I've never seen that, >> and I've used QtConcurrent::run/mapped + QFutureWatcher quite a lot. >> >> I would investigate that before making my own mechanism. >> > > I am on macos, on which OS are you doing it? > Windows, macOS and Linux. I had the same issue for FileSystemWatcher, where on windows it was > immediate and it was implemented on macos via polling. > I was thinking that it may be the same issue for QFutureWatcher. > > However, if we exclude QFutureWatcher, is this approach good? could it be > simplified? > I don't think so. But don't exclude QFutureWatcher. The proper thing to do is to investigate where the delay you're seeing is really coming from. There should not be any such delay inherent to QFutureWatcher, on any platform. I suspect you're blocking event processing/signal delivery somehow, but only you can answer that. Time all sections of your code to make sure you're not blocking the UI thread somewhere. We're using QtConcurrent/QFutureWatcher intensively in our product, running hundreds of jobs. If there was even the slightest such delay, our customers would yell like crazy :) Elvis > Also how would it be so different with a QFutureWatcher, it removes one > class TaskNotifier, but the rest stays the same, do you see another way > to make a action asynchrone? > > Best regards, > Sylvain > > > > >
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
