Monitoring a variable or an object changed asynchronously by a Callback function

I have a C style callback function for DDE communication, called asynchronously.
It works as it should.

Now I want this function to have a QBuffer or QLinkedList or at least an integer iterator
that should get a new value each time this callback function is executed.

I want to monitor the change of QBuffer from within my main function.

I could use void QIODevice::bytesWritten(qint64 bytes), but Signals and Slots are said to be ten times slower than callbacks.

Or shall I just implement a loop in my main function like this:

Code:

---

while (true)
{
  if myBuffer.changed()
      doSomething();
 
  QThread::msleep(SomeMilliseconds);
}

---

BTW, shall my QBuffer be a static variable?

There are two ways of recognizing change:

1) polling, e.g. calling a function periodically
2) notifications, e.g. callbacks, signal/slot

If you want to change from asynchronous notifications to synchronous polling, then let the callback set some indicator and then poll for a change of that indicator.

Cheers,
_

Yes, it is more or less that I thought.

Quote:

---

Originally Posted by sirop

Ibut Signals and Slots are said to be ten times slower than callbacks.

---

Out of curiosity, can you point me to a paper or some other engineering document that backs up these values?

Quote:

---

Originally Posted by wysota

Out of curiosity, can you point me to a paper or some other engineering document that backs up these values?

---

Compared to callbacks, signals and slots are slightly slower because of the increased flexibility they provide, although the difference for real applications is insignificant. In general, emitting a signal that is connected to some slots, is approximately ten times slower than calling the receivers directly, with non-virtual function calls.
http://doc.qt.io/qt-5.4/signalsandslots.html

While I'm sure it's true that a queued connection (Qt::QueuedConnection) is slower, Qt also provides a direct connection (Qt::DirectConnection) which is a function call. The default is Qt::AutoConnection, in which Qt will use the appropriate direct or queued connection.

When the signal is emitted from a different thread than the receiving slot, a queued connection must be used. I believe all other cases, a direct connection will be used for the same thread, unless you override the parameter on the connect statement and specify a Qt::QueuedConnection.

Quote:

---

Originally Posted by sirop

Compared to callbacks, signals and slots are slightly slower because of the increased flexibility they provide, although the difference for real applications is insignificant. In general, emitting a signal that is connected to some slots, is approximately ten times slower than calling the receivers directly, with non-virtual function calls.
http://doc.qt.io/qt-5.4/signalsandslots.html

---

"although the difference for real applications is insignificant". That's the important bit. If you spend even one hour of your time trying to work around an insignificant problem (e.g. by posting a question on a number of forums and reading the responses) then that's an hour wasted with no real compensation.

If signals and slots are convinient for you then use them, Qt uses them everywhere anyway so any potential gain in one place will not make any real difference. One silly function call (like calling sleep in your while loop) introduces a delay magnitudes larger than calling a slot.

Quote:

---

Originally Posted by wysota

"although the difference for real applications is insignificant". That's the important bit. If you spend even one hour of your time trying to work around an insignificant problem (e.g. by posting a question on a number of forums and reading the responses) then that's an hour wasted with no real compensation.

If signals and slots are convinient for you then use them, Qt uses them everywhere anyway so any potential gain in one place will not make any real difference. One silly function call (like calling sleep in your while loop) introduces a delay magnitudes larger than calling a slot.

---

Yesterday I was not sure yet how often and how fast my callback functions would be called,
that's why my question...

It will be an interval of some milliseconds. So I implemented a QTimer and it is fast enough.

Yes, calling sleep in my while loop is silly, and I found out why today.