I'm working now with Qt; I'm a bit mystified by their implementation of slots and signals (using 5.4 but could use old syntax too). I've looked all over for a good explanation of this part, but it's eluding me.
I used to create a slot and signal mechanism in other (non-Qt) projects. I'd have a message manager, and a routine with register with it that it wanted to send out a signal. It would send it to the message manager. Likewise a receiver would register with it that it wants to be notified of a signal. It would ask the message manager for that. Then, when a signal occurred, it would route it over to the listener. A sender didn't know how many (if any) listeners it had and a listener didn't know who might send that signal (if any).
I figured Qt worked like this, and I could still fake it by writing my own message manager, but it seems like slots and signals should take care of it. However, in all reading of slot and signal examples, it seems like that when the connection is made you need to know who the sender of the signal would be, and you connect it to your slot. However, what if the signal comes from multiple places? Do you have to wire it up to each and every module? That would seem to defeat the purpose, but every example I find shows it knowing where the signal is coming from.
Any clarification is appreciated.
This might shed some light. Taken from http://doc.qt.io/qt-5/signalsandslots.html
Slots are normal C++ functions ...
Related
I am using Evernote Android-Job library to schedule jobs.
In their documentation they state that the JobManager needs to be instantiated in the onCreate of the Application and they provide a workaround in case that's not possible relevant documentation section
The problem that I am facing is that method addJobCreator of the Broadcast receiver is never called even though the broadcast receiver is in the manifest. And ironically the only time I can get this method to be called is when i use JobManager.create(this) where this is an Activity context.
What am I doing wrong?
That's actually expected and works properly. The broadcast receiver needs to be called before any job can run. The library may call JobManager.create() for you and then call your receiver. That's early enough so that you can add your JobCreator.
I have a supervisor program that generally wants to receive SIGCHLD events. However, after it receives SIGTERM or similar signal, it would be safe and desirable to ignore SIGCHLD events to prevent zombies. The issue is that I'm not sure if it's legal to call signal(2) when already inside a signal handler, so that e.g. SIGTERM calls signal(SIGCHLD, SIG_IGN). It doesn't appear to cause problems, but I know there are many restrictions placed on what you can do in a signal handler, and I'm unable to figure out whether calling signal is in the forbidden zone.
So: is this legal, reliably? If not, is there an alternative way to make sure that no children still running at the time of the SIGTERM can possibly zombie, even if they aren't properly waited on?
For Linux, look at the manpage for signal(7). There is a list of async-signal-safe functions. It says:
POSIX.1-2004 (also known as POSIX.1-2001 Technical Corrigendum 2) requires an implementation to guarantee that the following functions can be safely called inside a signal handler:
signal() is in the list. So it's safe.
I'm an advanced beginner using Qt and I'm trying to write a console app that uses QFtp. The app itself is essentially just procedural code but because QFtp is asynchronous this is driving me crazy. I need to test that multiple ftp downloads are successful, but the code doesn't block so the test always fails. The best solution so far is to create a chain of signals and slots daisy chaining the ftp code and the procedural sections. It seems there has to be a better way. Any ideas?
You can use QEventLoop to wait for a signal. Just connnect the signal to QEventLoop::quit(), and then call QEventLoop::exec().
QFtp ftp;
QEventLoop eventLoop;
connect(&ftp, SIGNAL(commandFinished(int,bool)), &eventLoop, SLOT(quit()));
eventLoop.exec();
As it's asynchronous you're best off tracking it through the signal and slots mechanism, but that does throw off your procedural logic. The only other default option for FTP in Qt is QNetworkAccessManager but that's also asynchronous, so whichever you go for you're going to have to use the signal/slots system to track when it's done.
You could use QTcpSocket and write your own FTP code, that allows you to block the calling thread until it returns with certain conditions, but you'll have to write significantly more code to do what you want to.
I have several client GUI windows all derived from QMainWindow. Each window is potentially doing a different task but all are requesting data from a central cache implemented as a QThread.
All the clients connect to the same slot in the data cache and then emit signals to prompt the data cache to do something. The signals to the data cache get queued so the data cache only ever does one thing at a time.
When the data cache completes it needs to inform the correct client that the thing it was doing has completed. My immediate thought is to emit a signal to the requesting client about the completion. This would mean connecting to a specific client's slot and then emitting a signal to it.
Do I have to do connect and then disconnect to the client? I'm aware of the QObject::sender() function to get the supplier. Is there some way of emitting a signal to that sender (client) only? Or is there some other way of doing this?
There may be simpler approaches you can take to resolve your problem. For example, I would consider looking into the QtConcurrent framework. Alternately, you might also re-architect your design such that the client first connects to a "finished" signal on the cache prior to asking the cache to do anything. Failing all of that, you might also consider relying on the QMetaObject::invokeMethod function (for either your client or your cache). This function allows you to call an arbitrary method on an arbitrary QObject (provided that you have a pointer to it) using arbitrary generic arguments (in a way that's thread-safe).
If you use the QMetaObject::invokeMethod approach, there are a few of drawbacks you should be aware of. Firstly, you have to invoke the method using its string name, which means that you won't find out at compile time if you're using the wrong name. Secondly, since your clients have a different thread affinity than the central cache, there's a chance that the client will have been destroyed when the cache invokes the method on them (though perhaps in your case, this won't be a problem for you). Finally, you may not want your cache to have any knowledge of the names of the methods that it must execute on its client.
I don't have any way of getting around the first drawback (I'm not sure if this is going to be handled differently in the upcoming Qt 5.0 release). As far as the second and third problems, I would recommend creating an object that encapsulates a reference to a method -- something like the following:
class MethodReference
{
MethodReference(QObject* object, const QString& methodName);
...
bool invoke(QGenericArgument val0 = QGenericArgument(),
QGenericArgument val1 = QGenericArgument(),
...
QGenericArgument val9 = QGenericArgument());
private:
QPointer<QObject> mObject;
QString mMethod;
};
You would then pass this object to your cache from the client. The cache then calls invoke on this object.
Note the use of QPointer -- this gives you a thread-safe way of checking if your object has been destroyed before you try to invoke a method on it. Since I've done this before, I'll also let you know that versions of Qt prior to 4.8 had a bug in QPointer that would cause a crash in a multi-threaded context. Use a more recent version of Qt if you want to do this.
I hope this was clear.
I was digging into some source code I am working on. I found a peculiar statement that someone had coded. The source code is a GUI application with a QML GUI and uses QT 4.7.x.
The snippet below belongs to core application logic.
// connect signal-slots for decoupling
QObject::connect (this, SIGNAL(setCurrentTaskSignal(int)), this,
SLOT(SetCurrentTaskSlot(int)), Qt::QueuedConnection);
It's strange that the object connects to itself via a queued connection which essentially means that the object may "live" in different threads at the same time?
At first glance It didn't made any sense to me. Can anyone think of any reason why such a connection would be plausible or needed?. Would this even work?
It will work without any problem. Maybe there was some event loop processing required before calling SetCurrentTaskSlot?
Note that QueuedConnection doesn't mean that something is in different thread. QueuedConnection means only that when signal is emitted, corresponding slot won't be called directly. It will be queued on event loop, and will be processed when control will be given back to event loop
The queued connection implies nothing about where the receiver lives. The opposite is true: to safely send signals to an object living in another thread, you must use queued connections. But you can use them for an object living in any thread!
One uses a queued connection to ensure that the signal will be delivered from within the event loop, and not immediately from the emit site as happens with direct connection. Direct connection is conceptually a set of calls to function pointers on a list. Queued connection is conceptually an event sent to a clever receiver who can execute a function call based on the contents of the event.
The event is the internal QMetaCallEvent, and it is QObject::event that acts upon this event and executes the call.