I've been beating my head against a problem that I created.
Simply put, in Qt, you have signals and slots. The metaphor was that of wires; you connect a signal to a slot via a function called connect, which, for a framework that supports computer networking was not the best name for this function. Then again, what's the aphorism?
There are only two hard things in Computer Science: cache invalidation, naming things and off by one errors.
Concurrency also belongs in that list.
Usually when I learn something new, I prefer to do a deep dive so I know the thing...deeply.
I didn't have the opportunity to do that with Qt. Instead, I jumped into a project that was already using Qt and learned as I went, asking Grok about everything I didn't know.
When Grok explained connect with me, this was the pattern I was given:
connect(thread, SIGNAL(toStatusBar(QString, int, bool)), this, SLOT(toStatusBarECHO(QString, int, bool)))
In this example, thread will be the object that emits the signal. The signal is toStatusBar(). this is the this pointer of the current object, ergo, we're going to receive the signal. And when we do, we're going to call toStatusBarECHO().
The more seasoned readers among you might remember the term "event-driven programming". I'm old enough to remember the term, young enough to not have learned it properly. To me, event listeners on a webpage are examples of "event driven programming"; the clue's in the name.
Now, if you look at the code above, you might think that as soon as you call connect, the signal and the slot would immediately be connected in a if this, then that sort of way. If you think that, you would be wrong.
See, what I didn't know–and have been banging my head against for days–is that by default, Qt has a default parameter on connect of Qt::QueuedConnection. What that means is that there's a run loop and the connection will be made eventually.
But eventually wasn't good enough in my case.
In my architecture, I'm creating a thread to connect to a socket to do network communication. In fact, I create the thread on the fly inside of a wrapper object, do the networking and stop the thread. But I wanted to update the state machine inside the wrapper object by emitting a signal. With my limited understanding of how Qt works, I thought that once I called connect, the signal and the slot would be connected once the call completed. This caused a test to continuously fail because that was a faulty assumption.
Grok finally suggested using Qt::DirectConnection which caused my test to finally pass. And it's possible that an earlier architecture I had tried might have also worked had I know about Qt::QueuedConnection vs Qt::DirectConnection.
C'est la vie.
If you found anything useful in this post or want to support continued improvements to PacketSender, you can donate via PayPal.
I’m also open to new opportunities; feel free to reach out.
Top comments (0)