Why the task of QThread can not be executed until the function returns

For example:

void MainWidget::testThreadTask()
{
    qDebug() << "On test task";
}

void MainWidget::onBtnClick()
{
    QThread *thread = new QThread;
    connect(thread, QThread::started, this, testThreadTask);

    thread->start();
    qDebug() << "Thread START, now we wait 5s";

    QElapsedTimer timer;
    timer.start();
    
    while (timer.elapsed() < 5000)
    {
        
    }

    qDebug() << "END";
}

The program output is:

START wait 5s
END
On test task

I want to create a task to handle something after the button is pressed, and then the function will wait for the task to complete before returning.

In fact, it may not be necessary to create a new task and wait for it to execute, because since you have to wait and get stuck there, why not run it directly in the function.

But this is actually a problem when I deal with QT serial data. I want to send the data to the serial port after pressing the button, and then wait for the data (by constantly reading), but I find that when I have been waiting, the serial port can not read the data at all, only when I exit the function the serial port can read the data.

Is there any way to deal with serial data sending and receiving synchronization?

void MainWidget::onBtnClick()
{
    serial->write("Test");

    if (serial->bytesAvailable())
    {
        QByteArray data = serialIo->readAll();
        // handle the data
    }
}

You are mistaken about what is happening in your application. I suggest you read Threads and QObjects (the entire page), Qt::ConnectionType and the detailed description of QThread.

What is happening to you is:

• MainWidget does not live in thread. For the slot of a regular object to be called from thread, it first needs to be moved to that thread.<br/>Note that subclasses of QWidget cannot be moved to another thread. Because some OS supported by Qt limit where windows can live, they made the choice to force all QWidget to stay in the main thread, in all OS Qt can execute on.
• When you connect thread to this (which BTW is incorrect in your question, it should have been with ampersands connect(thread, &QThread::started, this, &MainWidget::testThreadTask);), you create a queued connection, even though the thread has not technically started yet.
• When you start the thread:
  1. It fires its started signal.<br/>
  2. Because the connection is a Qt::QueuedConnection, the slot will only be executed after returning to the main thread's event loop, i.e. some time after returning from onBtnClick.

Notes:

• You would have more useful information in qDebug() about the threads running your code by using QThread::currentThread().<br/>Even better than that, your IDE should provide you a window specifically to see what thread has reached a breakpoint (Ctrl+Alt+H on Visual Studio).
• At the risk of insisting, keep in mind this warning from the Qt help:<br/>
  Be aware that using direct connections when the sender and receiver live in different threads is unsafe if an event loop is running in the receiver's thread, for the same reason that calling any function on an object living in another thread is unsafe.<br/>
  With that said, because you wait 5 seconds before returning to the event loop and because it is only test code (= there should be no bug + it does not matter even if there is one), you should try to create a Qt::DirectConnection, just to see the slot be invoked from the worker thread.

The detailed description of QThread (link above) shows a complete working example of a worker object being moved to the new thread before it is started. The point is:

1. A worker object is created, then moved to the worker thread.
2. Connections are created for the controller to send QString to the worker object via signal/slot and for the worker object to return result to the controller via signal/slot too.<br/>
   All these connections are Qt::QueuedConnection by default since the worker object was moved.
3. The worker thread is started. Since run was not overriden, it starts an event loop (in exec).

And there you have it.

Remember 1 thing: widgets cannot be moved!!! Create your worker object as a separate class.