inherite from QThread, but donnot overrider virtual void run(), is this OK?

jsulm

@opengpu With int32 you have more than 2 million seconds, not 214783

opengpu

@opengpu said in inherite from QThread, but donnot overrider virtual void run(), is this OK?:

workerThread

workerThread donot need sleep?

jsulm

@opengpu said in inherite from QThread, but donnot overrider virtual void run(), is this OK?:

workerThread donot need sleep?

No, they are not humans :-)
Why are you asking? A thread can sleep or be busy.

opengpu

@jsulm ok, so it will automatically sleep when no signal or event, right?
because i used to overider the virtual run()
thanks

KroMignon

@kshegunov said in inherite from QThread, but donnot overrider virtual void run(), is this OK?:

This is a race condition - deleteLater is a slot and it's not thread-safe. Don't force the connection type.

Where did you found this information.... I mean not thread safe?
Because on Qt Mailing list, Thiago Macieira (which is deep involved in Qt devlopement) has written:

It's thread-safe with almost any operation, except one: the actual object's
deletion, of course.

But we haven't documented it as such. It just happens to be due to the
implementation.

==> cf. https://lists.qt-project.org/pipermail/interest/2015-October/019197.html

jsulm

@opengpu If you call exec() in your run() method then your thread will have an event loop and sleep if there is nothing to do. Else it will finish as soon as run() finishes (https://doc.qt.io/qt-5/qthread.html#run).

opengpu

@jsulm i used to not call exec, and use my own loop, so it need sleep, lol

kshegunov

@KroMignon said in inherite from QThread, but donnot overrider virtual void run(), is this OK?:

Where did you found this information.... I mean not thread safe?

Documentation. There's no promise Qt made about it being thread safe, and as Thiago noted this is an implementation detail you're relying on. It may change in Qt6 (it may even change in Qt5) and then you're going to wonder why a nasty bug suddenly appeared in your codebase.

kshegunov

@opengpu said in inherite from QThread, but donnot overrider virtual void run(), is this OK?:

QElapsedTimer m_ElapsedTimer;
if ( !m_ElapsedTimer.isValid() ||  m_ElapsedTimer.hasExpired(timeout))
{
    emit signalSendEmail();
    m_ElapsedTimer.restart();
}
i want to write like this, this will not restrict the 1st time emit, and since the 1st emit, the next emit is only allowed outof timeout milliseconds.
However, i want the exe runs very very long time. the qinit64 seems still not that long enough for the longest interval in theory(qint64 is only about 214783 seconds). What will happen if the real time interval is longer than this?
And what is the best method to get the longest time interval supportted in code?

// first emit
emit signalSendEmail(QDeadlineTimer(QDeadlineTimer::Forever));

// More emits
// ...
emit signalSendEmail(QDeadlineTimer::current() + 1000 * 3600); // 3600s = 1 hour

In the slot it's as easy to check as:

void Class::slotThatSendsEmails(const QDeadlineTimer & deadline)
{
    if (deadline.hasExpired())
        return;

    // Code that matters
}

KroMignon

@kshegunov said in inherite from QThread, but donnot overrider virtual void run(), is this OK?:

Documentation

Sorry, I don't want to be boring, I are certainly right...
But it would be nice if you can give me a pointer of your affirmation...
I am following Qt Forum to learn. You say I will have trouble doing this, but not really any information else...

jsulm

@KroMignon In documentation it is usually stated that a method is thread-safe (if it is), see for example bool QObject::disconnect
If there is no mention of thread-safety then you should assume it is not.

opengpu

@kshegunov said in inherite from QThread, but donnot overrider virtual void run(), is this OK?:

QDeadlineTimer

thank you, but why did you persist on using QDeadlineTimer?
donot emit the signal isn't better?
eg. watch on the stock price, as the price is changing very frequently, so i set this min-interval to forbid the alert too frequently(at most 1 time 1 interval-time).
that's my method, and i donnot is QDeadlineTimer better? or my code above has some bug...

opengpu

    ~Controller() {
        workerThread.quit();
        workerThread.wait(1000);
        workerThread.terminate();
    }

can i change the code in the doc like this?
because when i exit my exe, i found sometime it will block and wait such a long time. and that thread has no data should be saved, so i can stop that thread at any time.

kshegunov

@KroMignon said in inherite from QThread, but donnot overrider virtual void run(), is this OK?:

You say I will have trouble doing this, but not really any information else...

In short what @jsulm said. The long explanation goes like this:

I said you may fall into a trap relying on this. What you say is that the method's thread-safe, and it is, but this can change at any one point. Imagine someone needs to change something in Qt, the simplest example - say [s]he starts keeping a counter inside QObject for internal purposes and in some version [s]he adds a decrement in deleteLater, something along these lines:

void QObject::deleteLater()
{
    internalCounter--; //< And here trouble brews. This introduces a concurrency issue when called directly from different threads
    QCoreApplication::postEvent(this, new QDeferredDeleteEvent());
}

Now with the changed implementation you can't be sure that something in Qt won't leak because you call the method directly. Nor can you for that matter be sure that it won't break something. What I'm saying is that you're relying on a specific fixed implementation of the slot, which implementation, mind you, never was promised to be thread-safe to begin with. This means you're begging to tackle hard to diagnose bugs.

You can't nor should depend on how things are implemented inside Qt, but you should and must depend on what Qt promises you. If the method were documented as thread-safe, then it's the guys/gals changing the implementation who have the problem as [s]he has to keep the promise - i.e. being thread-safe; since its not documented as such [s]he can change it however [s]he likes as long as reentrancy isn't broken (QObject's methods are documented as reentrant).

PS.
You can take a look why you can't assume operator -- is atomic and is a concurrency issue; it expands to three separate instructions: https://godbolt.org/z/R1xrJQ
(the volatile is there to ensure the compiler doesn't optimize it out, which is a realistic case, the compiler may not be able to see and optimize it in a real-world case)

kshegunov

@opengpu said in inherite from QThread, but donnot overrider virtual void run(), is this OK?:

thank you, but why did you persist on using QDeadlineTimer?

I didn't. I wrote how you could implement deadlines for a signal-slot connection. I really have no idea how the whole application's supposed to work, so I can't know whether or not that's the right thing to do.

opengpu

@kshegunov thank you. and this is my code
https://forum.qt.io/topic/104026/about-the-longest-elapsed-time-in-qt/14