0

When processing requests in my qt server application sometimes I have to wait for a "resource" to become free. De to my understanding sleeping in the slot implementation would stop the mesasge loop, so this probably won't work as expected:

void MyClass::mySlot(/*some params here*/)
{
    while (resource.busy())
    {
        QThread::sleep(50);
        if (timeout)
            break;
    }
    if (!timeout) 
        doWork();
}

I thought of using QTimer e.g. with singleShot. My research shows, I cannot pass the parameters through the timer's signal.

My next approach would be to create an instance of a new object for each request, put the parameters to this request and use this object as recipient for the timer signal. In this slot I have to delete the request object because I haven't stored a reference to it (and don't want to).

void MyClass::mySlot(/*some params here*/)
{
    Request* request;
    request->setParams(...);
    request->processRequest();
}

void Request::processRequest()
{
    if (resource.busy())
    {
        // timeout missing in example/pseudocode
        QTimer::singleShot(50, this, SLOT(processRequest()));
    }
    else
    {
        doWork();
        delete this; // allowed by C++, but ugly. allowed by qt? better approach?
    }
}

Is there a better approach for freeing the request object or even a better approach for my problem? If not: is it valid to use delete this; in this context?

Chris
  • 1,508
  • 1
  • 11
  • 30
  • 1
    @πάνταῥεῖ Not duplicate (of that question, at least), this has a Qt specific answer. – hyde Jul 18 '14 at 20:18
  • I don't believe that there's something really [tag:qt] specific. `delete this` is wrong in most cases being asked for. – πάντα ῥεῖ Jul 18 '14 at 20:21
  • 1
    @πάνταῥεῖ `QObject::deleteLater()` is a very Qt specific answer to the question "is there a better approach". – hyde Jul 18 '14 at 20:43
  • @πάνταῥεῖ: you should really stop being commenting when you lack the minimal understanding. `QObject::deleteLater()` exists for a valid reason. What it has to do with the "delete this thread", I have no clue. It is a pity that we cannot remove from that reference from the top. – László Papp Jul 19 '14 at 04:46
  • @hyde: agreed, albeit it really is a duplicate as it has been asked several times. ;) – László Papp Jul 19 '14 at 04:47

1 Answers1

3

You can use QObject::deleteLater(). From the documentation :

Schedules this object for deletion. The object will be deleted when control returns to the event loop. If the event loop is not running when this function is called (e.g. deleteLater() is called on an object before QCoreApplication::exec()), the object will be deleted once the event loop is started. If deleteLater() is called after the main event loop has stopped, the object will not be deleted. Since Qt 4.8, if deleteLater() is called on an object that lives in a thread with no running event loop, the object will be destroyed when the thread finishes. Note that entering and leaving a new event loop (e.g., by opening a modal dialog) will not perform the deferred deletion; for the object to be deleted, the control must return to the event loop from which deleteLater() was called.

hyde
  • 60,639
  • 21
  • 115
  • 176
Murat Şeker
  • 1,651
  • 1
  • 16
  • 29