Thanks Alexander,
> I worked a bit on the qt example which is part of hpx:
> https://github.com/neundorf/hpx/tree/ModifiedQtExample/examples/qt
>
> I changed it so that it is now a "normal" Qt application which also uses
> HPX, instead of an HPX application wich also uses Qt.
> IOW, it now has a normal main, and the HPX thread pool is started on a
> button click via hpx_start().
> The HPX threads now use QEvents (via postEvent()) to get information into
> the Qt widgets.
> All the HPX code is now encapsulated in a QObject, which the actual
> application can use without any HPX code, i.e. simple function calls and
> Qt signals.
Marvelous!
I think there is no need to use an action for this. Actions are meant for
remote operation after all, where in your case no such remote work is
performed. You should be able to use the overload of hpx::async which
operates on local functions:
future<T> f = hpx::async([](...) {}, ...);
Additionally I believe this could be encapsulated into an HPX executor
object which would allow writing something like:
QtExecutor exec;
future<T> f = hpx::async(exec, [](...) {}, ...);
and have the lambda being executed as an Qt event. All of the facilities in
HPX which spawn new tasks accept executors, so this would directly integrate
with all of those (dataflow, parallel algorithms, future::then(), etc.). -
Just a thought.
> Please have a look and comment.
> I think this is an easier way to use HPX from a Qt application compared to
> the previous version.
Indeed!
> Please also have a look whether I'm using hpx_start() correctly and
> whether
> the way I start and stop the HPX "mainloop" (basically just waiting for an
> HPX condition variableI) is correct.
The idea of running hpx with start() is the following:
int hpx_main(int argc, char ** argv)
{
return hpx::finalize();
}
int main(int argc, char* argv[])
{
hpx::start(argc, argv);
std::cout << "Hello from the main thread!" << std::endl;
return hpx::stop();
}
Here stop() will block until finalize() has been called...
Essentially this is an alternative way to using hpx::init() which does not
block the progress on the main thread.
See here for an example on how these function can be used:
https://github.com/STEllAR-GROUP/hpx/blob/master/examples/quickstart/init_gl
obally.cpp
In short, I don't think you need your own condition variable to synchronize
with HPX shutting down.
> I'm also not sure about the number of threads in the threadpool. I thought
> I would get automatically as many threads as I have cores, but without
> command line parameters I got only one thread (on a 4 core CPU).
> Using command line parameters (--hpx:threads 4) works.
> Is this as it is intended or should I get the "correct" number of threads
> automatically ?
This is the default, yes. In order to have all cores used you can pass the
following configuration settings to hpx::start:
void QHpx::start()
{
std::vector<std::string> const cfg = {
"hpx.os_threads=all"
};
hpx::start(argc, argv, cfg);
hpx::register_thread(hpx::get_runtime_ptr(), "main");
}
>From what I can see, your code should not need the register_thread() above,
otherwise get_runtime_ptr() would return nullptr in the first place. IOW,
the thread executing QHpx::start seems to be already known to HPX (it is
probably the thread which executed main()).
> This is not yet a pull request. I know before that I have to have proper
> commit messages and no useless commits I guess.
Adding this example would be very welcome! We don't have anybody really
working with Qt on the team, so your experience is very much appreciated!
Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu
>
> Alex
>
> _______________________________________________
> hpx-users mailing list
> [email protected]
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
_______________________________________________
hpx-users mailing list
[email protected]
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
