Qt/Qml + RTI DDS Application

[anda_skoa]

Are requester::runReq() and replier::runRep blocking?

I.e. what is the reason you are using threads?

Cheers,
_

[PascalSevran]

Hello, yes, the runReq() function blocks until it receives a reply and the runRep() blocks until it receives a request.

With a similar project under Visual Studio, I gotta open both the requester.exe an the replier.exe in different cmd prompts to enable the communication between them.
With my Qt project I'd like to launch them and make them communicate with a simple click from my GUI, that's why I thought using threads was the only way, if it's not I'm opened to any suggestions

[anda_skoa]

I was mainly asking because the use of the moveToThread() approach suggests that the thread should use its default event loop.

Is the UI just triggering the start of the operations or is it somehow getting values back at some point?

Cheers,
_

[PascalSevran]

The UI shall display the results, so yes, the result of the request is theorically able to be available by the qml side thanks to setContextProperty(). However I notices that my UI isnt refreshing dynamically once the result is available, I read somewhere that I shall use QAbstractItemModel instead of setContextProperty().

As far as the threads are concerned, despite my use of the connect() method with the deleteLater() in the main.cpp, they don't seem to end properly and that's what is bothering me

[anda_skoa]

A model would most likely also be exposed as a context property, it really depends on how your result is created and how it is communicated to the QML scene.

How do you currently do that?

Cheers,
_

P.S.: Your connect finished->deleteLater is never triggered, since the threads are not told to quit.

[PascalSevran]

The result is generated by the DDS replier, then it is sent back to the DDS requester. When I receive it, I copy the value in a m_reqResult var, which is accessible from qml thanks to the setContextProperty() and the line :

Q_PROPERTY(int m_reqResult READ getResult WRITE setResult NOTIFY resultChanged)

Q_PROPERTY(int m_reqResult READ getResult WRITE setResult NOTIFY resultChanged)

To copy to clipboard, switch view to plain text mode 

in my requester class.

For the threads, should I emit a finished() signal in the end of my runReq() and runRep() functions ?

Thanks a lot

[anda_skoa]

Since your thread payload is "run once" and blocking it is probably cleaner to reimplement QThread::run() instead of "abusing" a thread with event loop, but yes, emitting signal at the end of the payload function should work as well.

Cheers,
_

[PascalSevran]

Ok so you're saying that instead of making the slot runReq() do the work I should transfer this work to the QThread::run() function which I can call since my requester class inherits from QObject, right ?

Thanks

[anda_skoa]

I am not quite sure I understand the question.

QThread::run() is executed by the new thread, its context is a lot like main().

The only thing you need to be careful about is creating QObjects in different thread contexts. If you create a QObject in a secondary thread you either destroy it before the thread ends or you move it to another thread, e.g. the application's main thread.

If you protect your property getters and setters with mutexes you can have a QObject in a secondary thread and use it from QML.
You can alternatively have the interface object live in the main thread and implement some of its methods in a way that they delegete to a thread.

You mentioned earlier that you had external processes instead of threads in a different implementation. You could still use that here as another alternative.

Cheers,
_

[PascalSevran]

Thanks a lot for your answers, I'll try to figure out how to deal with my threads based on what you said.

As far as splitting the requester and the replier onto 2 external processes, I really dont see how I could launch them from a GUI button click since they need to be running in paralel :s

[anda_skoa]

QProcess

Cheers,
_