On Monday 04 March 2013 23:56:35 Thiago Macieira wrote:
On terça-feira, 5 de março de 2013 08.54.35, André Somers wrote:
Op 5-3-2013 8:41, Thiago Macieira schreef:
On terça-feira, 5 de março de 2013 08.38.17, André Somers wrote:
I'd appreciate a reply on the point that when using a
On terça-feira, 5 de março de 2013 10.11.21, Olivier Goffart wrote:
Yes.
No.
If you do that, there is even a qWarning telling you there will be a race:
http://code.woboq.org/qt5/qtbase/src/corelib/thread/qfuturewatcher.cpp.html#
_ZN18QFutureWatcherBase13connectNotifyERK11QMetaMethod
You
On 2 March 2013 18:17, Andre Somers an...@familiesomers.nl wrote:
Actually, how do you feel about adding an optional _then_ argument to
the list of arguments of the functions in QtConcurrent and whatever is
decided to replace the QtConcurrent::run feature? Such a _then_ argument
could be a
Op 4-3-2013 16:17, Sze Howe Koh schreef:
On 2 March 2013 18:17, Andre Somers an...@familiesomers.nl wrote:
Actually, how do you feel about adding an optional _then_ argument to
the list of arguments of the functions in QtConcurrent and whatever is
decided to replace the QtConcurrent::run
On segunda-feira, 4 de março de 2013 17.25.35, André Somers wrote:
QFutureT runFunction(QFunctionT then, QFunctionT main);
QFutureT runFunction(QFuntionvoid then, QFuntionT main);
QFutureT runFunction(QFunctionT main);
I think this is going too far. If you want to chain jobs, we need a more
Op 4-3-2013 21:21, Thiago Macieira schreef:
On segunda-feira, 4 de março de 2013 17.25.35, André Somers wrote:
QFutureT runFunction(QFunctionT then, QFunctionT main);
QFutureT runFunction(QFuntionvoid then, QFuntionT main);
QFutureT runFunction(QFunctionT main);
I think this is going too far.
Yes, very much like that, but updated to also support the Qt5 like way
of connecting.
Yes, that could work. To make it truly optional though, the main
parallel function would have to be pre-bound by the programmer (e.g.
using https://codereview.qt-project.org/#change,45294), since the
On segunda-feira, 4 de março de 2013 22.00.34, Andre Somers wrote:
The point is to get notification when a job is done in the simples way
possible. Nothing more, nothing less, without having to check the status
of the future.
I understand what you want, but I don't want that. QFutureWatcher
On segunda-feira, 4 de março de 2013 14.49.15, Thiago Macieira wrote:
I think the proposed API addition is actually quite natural. It is not
without precedent (QTimer::singleShot()), and would result in quite
simple, readable code.
I disagree on both accounts. It's not natural: there is no
Op 4-3-2013 23:56, Thiago Macieira schreef:
On segunda-feira, 4 de março de 2013 14.49.15, Thiago Macieira wrote:
I think the proposed API addition is actually quite natural. It is not
without precedent (QTimer::singleShot()), and would result in quite
simple, readable code.
I disagree on
On Mar 4, 2013, at 11:56 PM, Thiago Macieira thiago.macie...@intel.com wrote:
Oh, and if you want simple, one more thing occurred to me:
runFunction([]() { main(); then(); });
If you need the return value:
runFunction([]() { then(main()); });
I will not accept C++11 isn't available
On terça-feira, 5 de março de 2013 08.38.17, André Somers wrote:
I'd appreciate a reply on the point that when using a QFutureWatcher,
you don't know if the future is already done or not at the moment you
connect.
It's not done, by construction.
--
Thiago Macieira - thiago.macieira (AT)
On Mar 5, 2013, at 8:38 AM, André Somers an...@familiesomers.nl
wrote:
I'd appreciate a reply on the point that when using a QFutureWatcher,
you don't know if the future is already done or not at the moment you
connect.
The intended usage of QFutureWatcher is that you set it up with
Op 5-3-2013 8:41, Thiago Macieira schreef:
On terça-feira, 5 de março de 2013 08.38.17, André Somers wrote:
I'd appreciate a reply on the point that when using a QFutureWatcher,
you don't know if the future is already done or not at the moment you
connect.
It's not done, by construction.
So,
On terça-feira, 5 de março de 2013 08.54.35, André Somers wrote:
Op 5-3-2013 8:41, Thiago Macieira schreef:
On terça-feira, 5 de março de 2013 08.38.17, André Somers wrote:
I'd appreciate a reply on the point that when using a QFutureWatcher,
you don't know if the future is already done or
On 27 February 2013 15:38, Laszlo Papp lp...@kde.org wrote:
On Wed, Feb 27, 2013 at 1:13 AM, Joseph Crowell joseph.w.crow...@gmail.com
wrote:
I have threads that live for the full life of my application but telling
them to stop on application shut down is painful.
What a coincidence. I
On Sun, Mar 3, 2013 at 10:15 AM, Sze Howe Koh szehowe@gmail.com wrote:
On 27 February 2013 15:38, Laszlo Papp lp...@kde.org wrote:
On Wed, Feb 27, 2013 at 1:13 AM, Joseph Crowell joseph.w.crow...@gmail.com
wrote:
I have threads that live for the full life of my application but telling
Op 22-2-2013 11:57, Sze Howe Koh schreef:
Some more common use case would be (pseudo-code)
auto watcher = new QFutureWatcher;
QObject::connect(watcher, SIGNAL(finished()), myObject, SLOT(doStuff()));
watcher-setFuture(QThrerad::run([]() { return computeStuff(); } ));
// who deletes the
On Tuesday 26 February 2013 20:02:31 Иван Комиссаров wrote:
My 2 cents. I would like to see something similar to Qt Creator's functions
implemented in runextensions.h in QtConcurrent module itself - methods
that allows to manipulate future using QFutureInterface (progress
notification, partial
On Wednesday 27 February 2013 11:13:35 Joseph Crowell wrote:
I have threads that live for the full life of my application but telling
them to stop on application shut down is painful. For this reason I
would like to be able to cancel a thread and also have a virtual
function to handle what
Subject: Re: [Development] Evolving Qt's multithreading API
If so, what's the cost of having two QObjects (trampoline object and
returned object), and how does it compare to the cost of deferring the
start until the next event loop iteration?
In my mind, the costs of 3 different approaches
On terça-feira, 26 de fevereiro de 2013 07.03.37, BRM wrote:
Personally, I can easily seem myself replacing my current QThread usages
with this functionality; but I'd want to be able to receive both
start/finished signals (for logging purposes) and be able to interact with
the QThread object -
My 2 cents. I would like to see something similar to Qt Creator's functions
implemented in runextensions.h in QtConcurrent module itself - methods that
allows to manipulate future using QFutureInterface (progress notification,
partial results).
Anyway, i wasn't able to find Qt Concurrent
From: Thiago Macieira thiago.macie...@intel.com
To: development@qt-project.org
Cc:
Sent: Tuesday, February 26, 2013 10:46 AM
Subject: Re: [Development] Evolving Qt's multithreading API
On terça-feira, 26 de fevereiro de 2013 07.03.37, BRM wrote:
Personally, I can easily seem myself
On 2/27/2013 2:12 AM, BRM wrote:
From: Thiago Macieira thiago.macie...@intel.com
To: development@qt-project.org
Cc:
Sent: Tuesday, February 26, 2013 10:46 AM
Subject: Re: [Development] Evolving Qt's multithreading API
On terça-feira, 26 de fevereiro de 2013 07.03.37, BRM wrote
: Tuesday, February 26, 2013 10:46 AM
Subject: Re: [Development] Evolving Qt's multithreading API
On terça-feira, 26 de fevereiro de 2013 07.03.37, BRM wrote:
Personally, I can easily seem myself replacing my current QThread
usages
with this functionality; but I'd want to be able
On segunda-feira, 25 de fevereiro de 2013 20.36.24, Sze Howe Koh wrote:
Thank you for the comprehensive explanation. I know little about Qt's
internal mechanisms, so I'm curious now.
Could the guarantee also be provided by posting QThread::start() into
the event loop during setup?
On 22 February 2013 21:58, André Somers an...@familiesomers.nl wrote:
Op 22-2-2013 14:31, Corentin Jabot schreef:
Think about QNetworkAccessManager :
reply = nam-get(url); // start the request
connect(reply, QNetworkReply::finished(), doSomething()); // you can
connect later
I think that
On 22 February 2013 21:31, Corentin Jabot corentin.ja...@gmail.com wrote:
Here again, two different issues.
1/ can we use the c++11 functional features and variadic templates
for the biding part.
2/ should we use the c++11 thread api somehow ( that looks like a huge
- unnecessary ? - change )
On 23 February 2013 00:11, Thiago Macieira thiago.macie...@intel.com wrote:
The fact is that any QObject that is returned from those functions -- if any
-- must belong to the calling thread. That implies the necessary guarantees in
terms of signal emissions.
For example, if the functions
On sábado, 23 de fevereiro de 2013 20.26.11, Sze Howe Koh wrote:
On 23 February 2013 00:11, Thiago Macieira thiago.macie...@intel.com
wrote:
The fact is that any QObject that is returned from those functions -- if
any -- must belong to the calling thread. That implies the necessary
I'm not sure what you mean. OpenMP, Pthreads and Boost threads are
independent; there is no backend here.
Anyway, as Thiago mentioned in another post, OpenMP is not supported
on all the compilers that Qt supports, so we can't use it in Qt.
(http://openmp.org/wp/openmp-compilers/)
Regards,
On 20 February 2013 22:45, Sze Howe Koh szehowe@gmail.com wrote:
Hi all,
Some time ago there was some talk about improving Qt's multithreading
API. I'm summarizing them here to stop them from fading into
obscurity, and to see if there's any interest in following them up.
Here are the
Op 22-2-2013 11:57, Sze Howe Koh schreef:
On Feb 22, 2013 12:33 AM, Olivier Goffart oliv...@woboq.com wrote:
Some more common use case would be (pseudo-code)
auto watcher = new QFutureWatcher;
QObject::connect(watcher, SIGNAL(finished()), myObject, SLOT(doStuff()));
2013/2/22 Sze Howe Koh szehowe@gmail.com:
Yes, that was my original plan. Someone complained that they couldn't
bind a function + arguments to QtConcurrent::run() first, then run it
at a later time. This approach gives them the opportunity to start it
whenever they want.
The problem is
Op 22-2-2013 14:31, Corentin Jabot schreef:
On second thought, I'm not sure if this would be commonly needed. We
can make it start immediately instead, BUT this requires a guarantee
that the first thread can always connect the finished() signal, before
the new thread runs and finishes. Can
2013/2/22 André Somers an...@familiesomers.nl
If only QFuture allowed you to connect... Unfortunately, it is not a
QObject
Oh yeah, I almost forgot that bit. And somehow it looks like the core issue.
I wonder why by the way:
We could have something like QObject - QFutureBase (with all
However, std::function and std::bind were already in tr1,
which AFAIK is already supported by all the compiler we support (Tier1 +
Tier2)
(MSVC 2008 and gcc 4.2 have it)
For VC 2008 it is part of an add-on pack [1], but it is available.
We could have something like QObject - QFutureBase
On sexta-feira, 22 de fevereiro de 2013 15.28.44, Corentin Jabot wrote:
2013/2/22 André Somers an...@familiesomers.nl
If only QFuture allowed you to connect... Unfortunately, it is not a
QObject
Oh yeah, I almost forgot that bit. And somehow it looks like the core issue.
I wonder why by
On sexta-feira, 22 de fevereiro de 2013 15.21.50, Olivier Goffart wrote:
Variadic template, we can clearly not rely on it. It only came in MSVC
really recently (patch release in nov 2012)
Yes, we can rely on it. That just means MSVC 2012 RTM doesn't get the feature.
As Marc put it, C++98
On sexta-feira, 22 de fevereiro de 2013 19.26.06, Sze Howe Koh wrote:
Actually, I just realized that the open-source flavour of TBB is
licensed under GPLv2 (http://threadingbuildingblocks.org/Licensing).
Doesn't that mean that Qt TBB, if it were to become reality, can't be
licensed under the
On 21 February 2013 02:16, Corentin Jabot corentin.ja...@gmail.com wrote:
Hi. I'm the one Olivier mentioned :p
I didn't have time to pursue further the work I started, but I intend
to, someday.
The plan, as suggested by thiago was to have a QThread::run(functor)
method acting exactly like
On 21 February 2013 02:31, Ing. Reynier Pupo Gómez rgo...@uci.cu wrote:
What about using of OpenMP standard? It could be very usefull and well known
by the C/C++ comunity.
Thanks for the suggestion. I had a quick look, but it seems to be on
the low-level side. I'm not sure if we want to use
On Friday 22 February 2013 00:07:28 Sze Howe Koh wrote:
On 21 February 2013 02:16, Corentin Jabot corentin.ja...@gmail.com wrote:
Hi. I'm the one Olivier mentioned :p
I didn't have time to pursue further the work I started, but I intend
to, someday.
The plan, as suggested by thiago
On sexta-feira, 22 de fevereiro de 2013 00.15.19, Sze Howe Koh wrote:
On 21 February 2013 02:31, Ing. Reynier Pupo Gómez rgo...@uci.cu wrote:
What about using of OpenMP standard? It could be very usefull and well
known
by the C/C++ comunity.
Thanks for the suggestion. I had a quick
Hi all,
Some time ago there was some talk about improving Qt's multithreading
API. I'm summarizing them here to stop them from fading into
obscurity, and to see if there's any interest in following them up.
Here are the tasks mentioned:
- Replace/Rewrite QtConcurrent [2]
- Create/Find a good API
Op 20-2-2013 15:45, Sze Howe Koh schreef:
Hi all,
Some time ago there was some talk about improving Qt's multithreading
API. I'm summarizing them here to stop them from fading into
obscurity, and to see if there's any interest in following them up.
There is also a proposal posted here:
On 20 February 2013 22:49, André Somers an...@familiesomers.nl wrote:
Op 20-2-2013 15:45, Sze Howe Koh schreef:
Hi all,
Some time ago there was some talk about improving Qt's multithreading
API. I'm summarizing them here to stop them from fading into
obscurity, and to see if there's any
On Wednesday 20 February 2013 22:45:21 Sze Howe Koh wrote:
Hi all,
Some time ago there was some talk about improving Qt's multithreading
API. I'm summarizing them here to stop them from fading into
obscurity, and to see if there's any interest in following them up.
Here are the tasks
On 20 Feb 2013, at 4:57 PM, Olivier Goffart wrote:
On Wednesday 20 February 2013 22:45:21 Sze Howe Koh wrote:
Hi all,
Some time ago there was some talk about improving Qt's multithreading
API. I'm summarizing them here to stop them from fading into
obscurity, and to see if there's any
Hello,
A few thoughts:
- In general and especially for newcomers, encourage task-orientated
concurrency and avoiding shared state where possible.
This partly about documentation and the examples but also in the kind of
approach that the APIs optimize for.
- Having had the er, pleasure of
One other thing - QtConcurrent::run(), QRunnable and invokeMethod() do not
provide any standard mid-task cancellation mechanism, which I've found to
be a very common need in the context of a client app which is offloading a
chunk of heavy work to background threads to avoid UI lag - eg. file
On 20 February 2013 23:57, Olivier Goffart oliv...@woboq.com wrote:
Someone has already been working of some feature such as:
...
https://codereview.qt-project.org/#/t/65/
Ah, these are quite similar to my second post
(http://lists.qt-project.org/pipermail/development/2013-February/009970.html).
On 21 February 2013 00:02, Rutledge Shawn shawn.rutle...@digia.com wrote:
On 20 Feb 2013, at 4:57 PM, Olivier Goffart wrote:
On Wednesday 20 February 2013 22:45:21 Sze Howe Koh wrote:
Hi all,
Some time ago there was some talk about improving Qt's multithreading
API. I'm summarizing them
Hi. I'm the one Olivier mentioned :p
I didn't have time to pursue further the work I started, but I intend
to, someday.
The plan, as suggested by thiago was to have a QThread::run(functor)
method acting exactly like QtConcurrent::run, but using a new QThead.
A similar QThreadPool::run function
What about using of OpenMP standard? It could be very usefull and well known
by the C/C++ comunity.
--
Linux Registered User: #515619
Linux Registered Machine: #421715
___
Development mailing list
Development@qt-project.org
On 21 February 2013 00:29, Robert Knight robertkni...@gmail.com wrote:
One other thing - QtConcurrent::run(), QRunnable and invokeMethod() do not
provide any standard mid-task cancellation mechanism, which I've found to be
a very common need in the context of a client app which is offloading a
57 matches
Mail list logo
