co_await vs QCoro::waitFor()?

[MicahSpikah]

When I'm connecting a Qt signal to a coroutine, does it make more sense to co_await the coroutine, or to use QCoro::waitFor?

For example, I have a class with member function that (ultimately) uses QIODevice to send a request and wait for response that I want to call at a certain interval:

connect( &timer, &QTimer::timeout, [ this ]() -> QCoro::Task<> { co_await request_data_from_serial(); } );

or

connect( &timer, &QTimer::timeout, [ this ] { QCoro::waitFor( request_data_from_serial() ) } );

Is it the same thing? If so, what about taking it a level further? I could either implement request_data_from_serial as

QCoro::Task<QByteArray> DeviceComm::request_data_from_serial()
{
    co_await send_request();
    co_return co_await get_response();
}

or

QByteArray DeviceComm::request_data_from_serial()
{
    QCoro::waitFor(send_request());
    return QCoro::waitFor(get_response());
}

The second way is attractive here because it lets me take the lambda out of the original connect call entirely and just make request_data_from_serial a "normal" slot.

The real thing driving this question is that I was originally connecting signals directly to coroutine lambdas, and letting them get more complicated than just 'call a member coroutine'. I got bit by a use-after-free bug (described here) and I'm doing what I can to get rid of all my capturing coroutine lambdas as advised by the C++ Core Guidelines here

[danvratil]

Hi,

regarding QCoro::waitFor(), there's one thing to consider: QCoro::waitFor() internally runs a nested QEventLoop - and it's always better to avoid nested QEventLoops due to potential re-entrancy issues. The construction of nested QEventLoop and the handling of things adds a small overhead, so it would make coroutines slightly more expensive.

But trhanks to the nature of QCoro's coroutines, you should be able to do

connect( &timer, &QTimer::timeout, this, &ThisClass::request_data_from_serial);

QCoro::Task is an eager coroutine (it starts automatically when called, it doesn't need to be co_awaited) and is designed specifically to run to its completion even when not co_awaited.

QCoro::waitFor() was intended for use in tests and when interfacing with code that doesn't support coroutines (i.e. calling coroutines from a QAbstractItemModel reimplementations).

There's also a third option: QCoro::Task::then(), so if you really wanted, you could do

QByteArray DeviceComm::request_data_from_serial()
{
    return QCoro::waitFor(send_request().then([this]() {
        return get_response();
    }));
}

Using .then() is more efficient than QCoro::waitFor() and doesn't use a nested event loops.

Just to showcase .then() chaining, you can do something like this:

void DeviceComm::request_data_from_serial(Callback callback)
{
    send_request().then([this]() {
        return get_response();
    }).then([this, callback = std::move(callback)](const QByteArray &response) {
        callback(response);
    });
}

There are many more variations possible of course, depends on your API design etc.

[MicahSpikah]

That makes sense! I was confused and assumed that a coroutine couldn't be called from a non-coroutine. But you're right, the Qt event loop was going to discard my QCoro::Task anyway, I can just ignore it myself and save the trouble. Thanks!