I've subclassed my Qthread so I can implement my code in run() method. I have to pass it some parameters,
I tried it like this, so what's wrong in here?
class QMyThread :
public QThread
{
public:
QMyThread();
~QMyThread(void);
virtual void start(FILE *data, int sock, int bits);
protected:
virtual void run(FILE *data, int sock, int bits);
};
run method;
void QMyThread::run(FILE *data, int sock, int bits)
{
//do stuff
}
start the thread:
QMyThread *thread;
thread->start(datafile, sockint, bitsint);
first it says the thread might not be initialized and then it crashes in the start() method with SIGSEGV error. Anyone can help me?
You shouldn't be subclassing the QThread class as this is no longer the recommended way of using QThread.
For more information http://qt-project.org/doc/qt-4.8/qthread.html
To answer your question, couldn't you just make those parameters members of your class and assign their values through setters or its contructor?
You should do this instead:
QMyThread thread;
thread.start(...)
You created a pointer to a thread and did not new it. I frankly see no reason for a pointer here, you can just create a normal variable and call a method on it.
If you do want a pointer, then use std::unique_ptr in C++11 or boost::unique_ptr
std::unique_ptr<QMyThread> thread;
thread->start(...);
EDIT:
You should really just create a QThread * thread = new QThread(this); as per the documentation.
How about using the QMetaObject class to pass the parameters to worker class. You can try like this:
QMetaObject::invokeMethod(worker, "methodName", Q_ARG(QString, "ParameterQStringValue");
Note this method will work if methodName is a slot and you use the new way of creating threads: https://mayaposch.wordpress.com/2011/11/01/how-to-really-truly-use-qthreads-the-full-explanation/
You can specify different parameters using Q_ARG macro up to 9 (http://doc.qt.io/qt-5/qmetaobject.html#details). If you need more parameters, then I suggest you to create the QVector with a structure and pass it to QMetaObject::invokeMethod as the parameter.
Related
I'm using VC++2017 to write a program to communicate with a PLC using Modbus. Ideally, I want to create a class that inherits from the MbusAsciiMasterProtocol but it's looking like that will be impossible. My current header file for it is:
#pragma once
#include "MbusAsciiMasterProtocol.hpp"
class PlcModbus
: public MbusAsciiMasterProtocol {
public:
/* Also tried without calling MbusAscii constructor and doesn't work*/
PlcModbus() : MbusAsciiMasterProtocol() {}
~PlcModbus() {}
};
and the part in the main function that uses it is
/* Doesn't work */
int dataArr[18];
PlcModbus plc;
plc.openProtocol("COM3", 19700L, 8, 1, 0);
plc.readMultipleLongInts(1, 1, dataArr, sizeof(dataArr) / sizeof(int)); // Breaks here
plc.closeProtocol();
Which throws a null pointer exception when it gets to plc.readMultipleLongInts (it successfully calls openProtocol and opens the connection). I did some digging with the debugger and found that the stack pointer after the function is called is 12 spaces away from where it was prior to the function call.
Now, if I don't inherit from MbusAsciiMasterProtocol and instead use the class directly, everything works fine.
/* Works fine */
int dataArr[18];
MbusAsciiMasterProtocol plc;
plc.openProtocol("COM3", 19700L, 8, 1, 0);
plc.readMultipleLongInts(1, 1, dataArr, sizeof(dataArr) / sizeof(int));
plc.closeProtocol();
There is no runtime error and I am able to communicate with the PLC. This makes absolutely no sense to me because up until this point I assumed that inheriting from a base class essentially gave you access to the same public and protected member functions within the base class. But this seems to imply otherwise.
I also tried to use MbusAsciiMasterProtocol as an object in PlcModbus and write wrappers around the functions I need, but that didn't work either and it gave the error "- The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention."
#pragma once
#include "MbusAsciiMasterProtocol.hpp"
class PlcModbus {
public:
PlcModbus() : myModbus(MbusAsciiMasterProtocol()) {}
~PlcModbus() {}
int openProtocol(const TCHAR *portName, long baudRate, int dataBits, int stopBits, int parity) {
return myModbus.openProtocol(portName, baudRate, dataBits, stopBits, parity);
}
int readMultipleLongInts(int slaveAddr, int startRef, int *int32Arr, int refCount) {
return myModbus.readMultipleLongInts(slaveAddr, startRef, int32Arr, refCount);
}
void closeProtocol() {
myModbus.closeProtocol();
}
public:
MbusAsciiMasterProtocol &myModbus;
};
I feel there must be something going wrong with the calls to the static library based off of that error, but why it works when I use the base class and not when I inherit from it is beyond me. Any explanation about what's going on would be extremely helpful.
Cheers.
I don't know why inheriting from MbusAsciiMasterProtocol doesn't work for you.
However in your last code example where you write wrappers around functions you have one subtle error:
MbusAsciiMasterProtocol &myModbus; creates a reference to MbusAsciiMasterProtocol object.
In the constructor you are initializing it with MbusAsciiMasterProtocol() - a temporary object thus creating a reference to a temporary. This is probably the source of the errors you are getting. Remove the reference and make the object private instead of public.
I have something like this:
class Thing : public QObject {
...
public slots:
void doSomething ();
...
};
I then have an object that manages Things, like this:
class ManyThings : public QObject {
...
public:
void makeThingDoSomething (int thingIndex);
private:
QVector<Thing *> things_;
...
};
My question is this: The Things in ManyThing's collection are scattered among a few different threads. I'd like makeThingDoSomething(int) to call the things_[thingIndex]->doSomething() slot as if the slot was called from a signal connected with Qt::AutoConnection. Essentially this, but using Qt's queuing mechanism if the Thing is on a different thread than the caller:
void ManyThings::makeThingDoSomething (int thingIndex) {
// i want to do this AutoConnection style, not direct:
things_[thingIndex]->doSomething();
// doesn't *need* to block for completion
}
What's the simplest way to set this up? I could make a signal in ManyThings and connect it to each of the Thing's slots, but then emitting that signal would call the slot on every Thing, not just a specific one. Is there some way to easily set up connections so that I can connect the same signal to different object's slots depending on an index parameter passed to the signal, or something? Or some way to call the slot using Qt's signal/slot mechanism without actually having to create a signal?
Try using QMetaObject::invokeMethod:
void ManyThings::makeThingDoSomething(int thingIndex) {
QMetaObject::invokeMethod(things_[thingIndex], "doSomething",
Qt::AutoConnection);
}
Note that doSomething will likely have to remain a slot if you use this approach.
i have a public class , in that class i have a void which sets Clipboard.Text and i have a thread from which i call that func, everytime i call it i get
Current thread must be set to single thread apartment (STA) mode before OLE calls can be made. Ensure that your Main function has STAThreadAttribute marked on it.
I have tried the following :
Thread t = new Thread(Worker);
t.SetApartmentState(ApartmentState.STA);
t.Start();
But i still recieve error, i even tried [STAThread]
My function looks like this
public void Set(string s)
{
Clipboard.SetText(s);
}
I believe it is telling you put put the STAThread attribute on your main function, like so:
[STAThread]
static void Main()
{
// Your code
}
You said you tried STAThread, but was it on the main function or the function you're calling?
The QFuture class has methods such as cancel(), progressValue(), etc. These can apparently be monitored via a QFutureWatcher. However, the documentation for QtConcurrent::run() reads:
Note that the QFuture returned by
QtConcurrent::run() does not support
canceling, pausing, or progress
reporting. The QFuture returned can
only be used to query for the
running/finished status and the return
value of the function.
I have looked in vain for what method actually can create a QFuture that can be cancelled and report progress for a single long-running operation. (It looks like maybe QtConcurrent::map() and similar functions can, but I just have a single, long-running method.)
(For those familiar with .Net, something like the BackgroundWorker class.)
What options are available?
Though it's been a while since this question was posted and answered I decided to add my way of solving this problem because it is rather different from what was discussed here and I think may be useful to someone else. First, motivation of my approach is that I usually don't like to invent own APIs when framework already has some mature analogs. So the problem is: we have a nice API for controlling background computations represented by the QFuture<>, but we have no object that supports some of the operations. Well, let's do it. Looking on what's going on inside QtConcurrent::run makes things much clearer: a functor is made, wrapped into QRunnable and run in the global ThreadPool.
So I created generic interface for my "controllable tasks":
class TaskControl
{
public:
TaskControl(QFutureInterfaceBase *f) : fu(f) { }
bool shouldRun() const { return !fu->isCanceled(); }
private:
QFutureInterfaceBase *fu;
};
template <class T>
class ControllableTask
{
public:
virtual ~ControllableTask() {}
virtual T run(TaskControl& control) = 0;
};
Then, following what is made in qtconcurrentrunbase.h I made q-runnable for running this kind of tasks (this code is mostly from qtconcurrentrunbase.h, but slightly modified):
template <typename T>
class RunControllableTask : public QFutureInterface<T> , public QRunnable
{
public:
RunControllableTask(ControllableTask<T>* tsk) : task(tsk) { }
virtial ~RunControllableTask() { delete task; }
QFuture<T> start()
{
this->setRunnable(this);
this->reportStarted();
QFuture<T> future = this->future();
QThreadPool::globalInstance()->start(this, /*m_priority*/ 0);
return future;
}
void run()
{
if (this->isCanceled()) {
this->reportFinished();
return;
}
TaskControl control(this);
result = this->task->run(control);
if (!this->isCanceled()) {
this->reportResult(result);
}
this->reportFinished();
}
T result;
ControllableTask<T> *task;
};
And finally the missing runner class that will return us controllable QFututre<>s:
class TaskExecutor {
public:
template <class T>
static QFuture<T> run(ControllableTask<T>* task) {
return (new RunControllableTask<T>(task))->start();
}
};
The user should sublass ControllableTask, implement background routine which checks sometimes method shouldRun() of TaskControl instance passed to run(TaskControl&) and then use it like:
QFututre<int> futureValue = TaskExecutor::run(new SomeControllableTask(inputForThatTask));
Then she may cancel it by calling futureValue.cancel(), bearing in mind that cancellation is graceful and not immediate.
I tackled this precise problem a while ago, and made something called "Thinker-Qt"...it provides something called a QPresent and a QPresentWatcher:
http://hostilefork.com/thinker-qt/
It's still fairly alpha and I've been meaning to go back and tinker with it (and will need to do so soon). There's a slide deck and such on my site. I also documented how one would change Mandelbrot to use it.
It's open source and LGPL if you'd like to take a look and/or contribute. :)
Yan's statement is inaccurate. Using moveToThread is one way of achieving the proper behavior, but it not the only method.
The alternative is to override the run method and create your objects that are to be owned by the thread there. Next you call exec(). The QThread can have signals, but make sure the connections are all Queued. Also all calls into the Thread object should be through slots that are also connected over a Queued connection. Alternatively function calls (which will run in the callers thread of execution) can trigger signals to objects that are owned by the thread (created in the run method), again the connections need to be Queued.
One thing to note here, is that the constructor and destructor are running in the main thread of execution. Construction and cleanup need to be performed in run. Here is an example of what your run method should look like:
void MythreadDerrivedClass::run()
{
constructObjectsOnThread();
exec();
destructObjectsOnThread();
m_waitForStopped.wakeAll();
}
Here the constructObjectsOnThread will contain the code one would feel belongs in the constructor. The objects will be deallocated in destructObjectsOnThread. The actual class constructor will call the exit() method, causing the exec() to exit. Typically you will use a wait condition to sit in the destructor till the run has returned.
MythreadDerivedClass::~MythreadDerivedClass()
{
QMutexLocker locker(&m_stopMutex);
exit();
m_waitForStopped.wait(locker.mutex(), 1000);
}
So again, the constructor and destructor are running in the parent thread. The objects owned by the thread must be created in the run() method and destroyed before exiting run. The class destructor should only tell the thread to exit and use a QWaitCondition to wait for the thread to actually finish execution. Note when done this way the QThread derived class does have the Q_OBJECT macro in the header, and does contain signals and slots.
Another option, if you are open to leveraging a KDE library, is KDE's Thread Weaver. It's a more complete task based multitasking implementation similar QtConcurrentRun in that it leverages a thread pool. It should be familiar for anyone from a Qt background.
That said, if you are open to a c++11 method of doing the same thing, I would look at std::async. For one thing, you will no longer have any dependance on Qt, but the api also makes more clear what is going on. With MythreadDerivedClass class inheriting from QThread, the reader gets the impression that MythreadDerivedClass is a thread (since it has an inheritance relationship), and that all its functions run on a thread. However, only the run() method actually runs on a thread. std::async is easier to use correctly, and has fewer gotcha's. All our code is eventually maintained by someone else, and these sorta things matter in the long run.
C++11 /w QT Example:
class MyThreadManager {
Q_OBJECT
public:
void sndProgress(int percent)
void startThread();
void stopThread();
void cancel() { m_cancelled = true; }
private:
void workToDo();
std::atomic<bool> m_cancelled;
future<void> m_threadFuture;
};
MyThreadedManger::startThread() {
m_cancelled = false;
std::async(std::launch::async, std::bind(&MyThreadedManger::workToDo, this));
}
MyThreadedManger::stopThread() {
m_cancelled = true;
m_threadfuture.wait_for(std::chrono::seconds(3))); // Wait for 3s
}
MyThreadedManger::workToDo() {
while(!m_cancelled) {
... // doWork
QMetaInvoke::invokeMethod(this, SIGNAL(sndProgress(int)),
Qt::QueuedConnection, percentDone); // send progress
}
}
Basically, what I've got here isn't that different from how your code would look like with QThread, however, it is more clear that only workToDo() is running on the thread and that MyThreadManager is only managing the thread and not the thread itself. I'm also using MetaInvoke to send a queued signal for sending our progress updates with takes care of the progress reporting requirement. Using MetaInvoke is more explicit and always does the right thing (doesn't matter how you connect signals from your thread managers to other class's slots). You can see that the loop in my thread checks an atomic variable to see when the process is cancelled, so that handles the cancellation requirement.
Improve #Hatter answer to support Functor.
#include <QFutureInterfaceBase>
#include <QtConcurrent>
class CancellationToken
{
public:
CancellationToken(QFutureInterfaceBase* f = NULL) : m_f(f){ }
bool isCancellationRequested() const { return m_f != NULL && m_f->isCanceled(); }
private:
QFutureInterfaceBase* m_f;
};
/*== functor task ==*/
template <typename T, typename Functor>
class RunCancelableFunctorTask : public QtConcurrent::RunFunctionTask<T>
{
public:
RunCancelableFunctorTask(Functor func) : m_func(func) { }
void runFunctor() override
{
CancellationToken token(this);
this->result = m_func(token);
}
private:
Functor m_func;
};
template <typename Functor>
class RunCancelableFunctorTask<void, Functor> : public QtConcurrent::RunFunctionTask<void>
{
public:
RunCancelableFunctorTask(Functor func) : m_func(func) { }
void runFunctor() override
{
CancellationToken token(this);
m_func(token);
}
private:
Functor m_func;
};
template <class T>
class HasResultType
{
typedef char Yes;
typedef void *No;
template<typename U> static Yes test(int, const typename U::result_type * = 0);
template<typename U> static No test(double);
public:
enum { Value = (sizeof(test<T>(0)) == sizeof(Yes)) };
};
class CancelableTaskExecutor
{
public:
//function<T or void (const CancellationToken& token)>
template <typename Functor>
static auto run(Functor functor)
-> typename std::enable_if<!HasResultType<Functor>::Value,
QFuture<decltype(functor(std::declval<const CancellationToken&>()))>>::type
{
typedef decltype(functor(std::declval<const CancellationToken&>())) result_type;
return (new RunCancelableFunctorTask<result_type, Functor>(functor))->start();
}
};
User example:
#include <QDateTime>
#include <QDebug>
#include <QTimer>
#include <QFuture>
void testDemoTask()
{
QFuture<void> future = CancelableTaskExecutor::run([](const CancellationToken& token){
//long time task..
while(!token.isCancellationRequested())
{
qDebug() << QDateTime::currentDateTime();
QThread::msleep(100);
}
qDebug() << "cancel demo task!";
});
QTimer::singleShot(500, [=]() mutable { future.cancel(); });
}
For a long running single task, QThread is probably your best bet. It doesn't have build-in progress reporting or canceling features so you will have to roll your own. But for simple progress update it's not that hard. To cancel the task, check for a flag that can be set from calling thread in your task's loop.
One thing to note is if you override QThread::run() and put your task there, you can't emit signal from there since the QThread object is not created within the thread it runs in and you can't pull the QObject from the running thread. There is a good writeup on this issue.
Let's say I have
class classA {
void someMethod()
{
Thread a = new Thread(threadMethod);
Thread b = new Thread(threadMethod);
a.Start();
b.Start();
a.Join();
b.Join();
}
void threadMethod()
{
int a = 0;
a++;
Console.Writeline(a);
}
}
class classB {
void someMethod()
{
Thread a = new Thread(threadMethod);
Thread b = new Thread(threadMethod);
a.Start();
b.Start();
a.Join();
b.Join();
}
static void threadMethod()
{
int a = 0;
a++;
Console.Writeline(a);
}
}
Assuming that in classA and classB, the contents of threadMethod have no effect to anything outside of its inner scope, does making threadMethod in classB static have any functional difference?
Also, I start two threads that use the same method in the same class. Does each method get its own stack and they are isolated from one another in both classA and classB?
Does again the static really change nothing in this case?
Methods don't have stacks, threads do. In your example threadMethod only uses local variables which are always private to the thread executing the method. It doesn't make any difference if the method is static or not as the method isn't sharing any data.
In this case there is no functional difference. Each thread gets it's own stack
Maybe you can be a little more clear. It doesn't matter if the function is declared static or not in most languages. Each thread has its own private statck.
Each thread would get it's own stack. There is no functional difference that I can tell between the two.
The only difference (obviously) is that the static version would be unable to access member functions/variables.