QMutexLocker - SignalWaiter - how does the example work?

kaivolde

Hi all,

in the docs for the class QMutexLocker there is an outline of an example for a SignalWaiter given.
It is only an outline. Can somebody give me the details how it will work?

I have to solve the following problem:

I have a method like this:
int SomeClass::myMethod()
{
// here I have access to a socket. I must start some network-communication
// over the socket to get the result for the method. E.g.

   mySocket->sendCommand( "someCommandId" );

   // The method should now wait till the result is there (or some error occurs).
   // So I want to wait for the readyRead-Signal now.
   // Can the SignalWaiter-class be used for it? How?

}

I know that the Qt socket class already has some waitFor...-methods. But using these methods on Windows is not encouraged (...using this method will randomly fail on Windows...). What can I say? I'm on Windows.... So I'm looking for an alternative.

Here is the example from the Qt-docs of QMutexLocker:

class SignalWaiter
{
private:
QMutexLocker locker;

public:
SignalWaiter(QMutex *mutex)
: locker(mutex)
{
}

void waitForSignal()
{
    ...
    while (!signalled)
        waitCondition.wait(locker.mutex());
    ...
}

};

Thanks in advance,
Best regards

Kai

SGaist

Hi,

Not a direct answer but I would have rather used a QEventLoop for that or the old QxtSignalWaiter class which does the job well.

Out of curiosity, why do you need such a blocking behavior ?

kaivolde

Hi Samuel,

thanks for the suggestions. I will take a look at the QxtSignalWaiter. I think it will do exactly what I want. Of course it is a "little overhead" using a whole new library for solving my little problem.

What do you mean by "using the QEventLoop"? So far I have solved my problem with code like this:

while ( ! _isReadyRead ) {
     // the boolean-variable _isReadyRead will be set inside of the slot which is called by the readyRead()-Signal
    QCoreApplication::processEvents();
}

But very often code like this is described as an "ugly hack".

So I'm just looking for a better and elegant solution....

** Why do you need such a blocking behavior ?
Little bit complicated to explain, a try: I have a main-program which I can't modify. The code which I can implement and modify is some plugin-code for the main-program. The main-program expects immediate results. When it calls the plugin-method myMethod which is implemented inside of the plugin a result has to be returned. I can't switch the main-program to asynchronous signal-slot-communication.

int SomeClass::myMethod()
{
// do some calculation here
// and return the result of the calculation
return myResult;
}

Ok?

Best regards
Kai

SGaist

IIRC, it's self-contained so You can extract it from the library.

What I have seen in use:

QEventLoop loop;
connect(mySocket, &QTcpSocket::readyRead, &loop, &QEventLoop::exit);
loop.exec();

Which work a bit like a modal dialog.

Ok, I see your use case, a classic.