need ideas for list/table implementation

kshegunov

@mzimmers said in need ideas for list/table implementation:

Noted, but I don't think that's causing my quit button to be ignored, is it?

Probably not, although it would eventually cause a segafault somewhere.

I just realized my process() routine is only called once. Is there something wrong with my pollTimer?

Not that I can see. Are you sure this:

len = sm.recv(buffIn, sizeof(buffIn));

isn't blocking? (also the reason for my question why aren't you using Qt's sockets)

kshegunov

@VRonin said in need ideas for list/table implementation:

No need to give parents to stack-allocated QObjects like devices or pollTimer

That is incorrect! It's quite needed.

mzimmers

The socket call might block, but only for a few seconds. I just stepped through the code, and discovered that worker::start() is never called. In main, I have:

    worker->moveToThread(thread);
     ...
    thread->start();

Am I supposed to explicitly call worker::start()?

No good reason for using native sockets; I'm just re-using code that I implemented on the target device (which sadly doesn't have Qt [yet]). But I'm fairly sure they're not the problem here. Remember this was (sort of) working once, before VRonin MOG'd me and I started making changes.

kshegunov

Am I supposed to explicitly call worker::start()?

No, not really. Do you have that:

QObject::connect(thread, &QThread::started, worker, &Worker::start);

before calling thread->start();?

mzimmers

Well, I didn't (the slot was process, not start), but I do now...same result.

Is there a way to see whether this slot is actually getting invoked:

    QObject::connect(&widget, &Widget::quitButtonPushed, thread, &QThread::quit);

I have verified the signal in the debugger.

EDIT:

Wait a minute: I just realized I'm doing this a little differently than I have in the past, in that the worker, not the widget is in the new thread. I think maybe I am exiting the worker, but I still have to stop the main/widget thread. Since main() isn't a Qt object, I can't use connect, so what's the recommended technique here?

kshegunov

@mzimmers said in need ideas for list/table implementation:

Is there a way to see whether this slot is actually getting invoked:

Subclass QThread for the testing purposes and override run(). In the run implementation only do:

void MyThread::run()
{
    int ret = QThread::exec();
    qDebug() << "ret"; //< If you get to here with the debugger, then the `quit` was called.
}

kshegunov

@mzimmers said in need ideas for list/table implementation:

Wait a minute: I just realized I'm doing this a little differently than I have in the past, in that the worker, not the widget is in the new thread. I think maybe I am exiting the worker, but I still have to stop the main/widget thread. Since main() isn't a Qt object, I can't use connect, so what's the recommended technique here?

You have QApplication for that purpose and you can get it from anywhere with QCoreApplication::instance(). Connect the quit button to the application quit slot as well as to the thread quit slot. Don't forget to wait for the worker thread to finish (call QThread::wait) before exiting the application.

VRonin

emit newMessage(&msg) is (probably) still a race condition, msg.decodeXml might (and almost surely does) get called before the slots connected to the signal had the time to read the last one. Either serialise access inside Message via stuff like QReadWriteLock or emit passing by value

mzimmers

@kshegunov so my exit button now triggers two calls:

    QApplication a(argc, argv);
    Widget widget;
    QThread* thread = new QThread;
  ...
    QObject::connect(&widget, &Widget::quitButtonPushed, thread, &QThread::quit);
    QObject::connect(&widget, &Widget::quitButtonPushed, &a, &QApplication::quit);

Regarding QThread::wait(), according to the docs:

Blocks the thread until either of these conditions is met

(where one of the conditions is the thread finishes)

So, presumably, what documentation means is that the routine blocks the deletion of the thread, not the thread itself, right? So I can call the wait() routine like this?

    widget.show();
    thread->start();
    thread->wait();
    rc = a.exec();

EDIT:

wrong.

OK, so where should the thread wait call go?

VRonin

You can connect &QThread::finished insetad of &Widget::quitButtonPushed to &QApplication::quit for the application to wait for the thread to finish before closing down

mzimmers

Perfect. Thanks for the help on threads.

And speaking of threads, this one has gone afield enough that I think it's best to consider it finished. Thanks to everyone who provided input on this.