I have two Qt apps sharing a memory segment.
I would like to be able to emit a signal from App2 and trigger a slot from App1.
First off, I need to use QObject::connect() to link the App2 signal to the App1 slot.
Is there a good way to connect two different Qt processes signals/slots mechanisms? I've stumbled upon the qt-remote-signals library to send remote signals, which is using QDataStream to serialize the object. QSharedMemory uses the same class.
Or should I forget about connecting anything and just simulate a signal/slot behaviour?
Write in the memory segment from App2
Read the segment whenever it changes from App1 (how to know when it is updated?)
Emit a custom signal from App1
Trigger a slot from App1
Does that sound realistic ? I'm new to shared memory.
As far as I know, you can't connect Signal/Slot between processes. Also you cannot know 'naturaly' if another process have changed a QSharedMemory.
So I think you'll have to simulate it as you said.
Write in the memory segment from App2
App 1 could be checking periodically the segment, to being aware of changes from App 2. Once a change is done, you directly trigger the slot (you don't really need the signal)
If you need an instantly response (without making the App 1 checking time too small) from App1 you could make them comunicate using QLocalSocket/Server or D-Bus, butin that case you could go all in with them and manage all the comunication, making the QSharedMemory unnecesary.
Related
I am developping a project about data sampling and realtime display like oscilloscope. The data are transfered to PC with virtual com port at a high trandfer rate. I am using QT4.8.4 + Qextserialport to accomplish serial port communication on WindowsXP.
I have tested the device using AccessPort. It could receive the data from the port, but have no response to write to it. If I wanted to make the device stop uploading data, I must stop the device and write stop command to it, restarted the device, then the device stopped uploading. It is the same for the application using one thread to process reading and writing. I did not want to close the port completely. I just wanted to enter some command to change something, the sampling rate, the data format, etc.
So, I tried multithread. I downloaded a reference code from the following link.
http://www.qtcentre.org/threads/21063-QextSerialPort-with-QTimer-approch-for-reading?p=103325&highlight=#post103325
(I am sorry, I really do not know how to paste code fitly on this site)
In this code, the author derived two subclass of QThread. One is for reading port, the other is for writing port. He also reimplemented the run() in these two subclass. I tried this code, but found that when receiving code, my GUI frozen.
It seem that the author in the following thread met the same question with me.
Qt: GUI sometimes freezing when using threads and signals/slots
But I have question about this thread.
The author mentioned "When running the code in the GUI-thread, there is no problem."
Did the author mean that everything is OK when the all code in GUI-thread? So, why he used worker thread and process thread?
The author mentioned "Process thread"
Do I need a another process thread to work with GUI thread which is responsible for display?(I need to display not only the data but also the waveform, all must in realtime)
Please give me some tips on how to conquer this problem. Thanks a lot.
The short answer is yes. Doing any heavy processing on a GUI thread will result in freezing the GUI (esp if you block). Instead you should either have an independent thread that updates the data, or spin off worker threads for specific tasks. In either case, when there is new data to display you should signal the GUI thread when there is new data to display. If possible, I'd recommend using the MVC pattern and implement a QAbstractItemModel to provide data to your view (as it has a defined pattern for providing those updates).
I'm new to Qt so please excuse the simplicity of the question but I'm a bit confused on the Qt threading. Let's say I have 3 threads: the main default GUI thread, and 2 threads of my own creation (called WorkerThread). Each of my WorkerThreads inherits from QThread and are permanent threads that every so often wake up and send data out a socket and post status on a GUI element. How is the best way to 1) allow the GUI thread to set data in the WorkerThread object that the WorkerThread thread can use? 2) allow the WorkerThread to send status to the GUI thread to be displayed for the user? 3) Allow both WorkerThreads to use the same socket?
It seems from the documentation that when I create a WorkerThread object it is owned by the creating thread (except for the run method that is a new thread). So how does one set data for the new thread to execute on? Must all the data the new thread uses be global? For instance, I would like the GUI to allow the user to select a packet type for each of the WorkerThreads to send when they wake up. I had assumed that I would put in some slots in the WorkerThread that the GUI thread would signal. When the WorkerThread object received a signal to SetPacketType it would set a member variable that the run method references on each iteration. But after reading the documentation I'm not sure that is the way to do it. If the WorkerThread object is owned by the creating thread (GUI thread in this case) then sending signals to it doesn't cross thread boundaries does it?
Also, what is the proper technique for sharing the socket connection across threads?
Thanks in advance.
With Qt, the easiest way to send information between threads is to use signals and slots. Qt automatically uses queued signals for connections between threads (see Qt::ConnectionType), which ensures that a signal can be emitted from one thread, but the slot will be executed in the thread of the receiver object.
If the data being sent between threads (work to be done or status information) is something that Qt can automatically queue (e.g., QStrings, built-in types like int and double, and others), then passing the info as the arguments to the signal/slot is the best way to send the info. If large or complex data is being shared, then you either need to use qRegisterMetaType to allow Qt to copy the data, or pass a pointer to a thread-safe object. Unlike what Pie_Jesu said, the threads do share an address space so you can share pointers; just make sure that one thread's interaction with the shared object won't interfere with another thread's interactions.
QTcpSocket is not thread-safe (it's only reentrant according to Qt's documentation), so if you share the socket you will have to be responsible for ensuring that threads don't use the socket in conflicting ways.
I'm working with threads in C++/Qt, each one to establish and mantain a QTcpSocket connection.
The problem is that when a disconnection from network comes, those threads must reconnect in a certain order. That's already working, but I have another problem: I need to know into each thread if only current thread has been disconnected, or all of them have been disconnected.
The first idea I had was to pass every thread a reference to a class where I would be able to store each thread status and check everyone else's.
But then I had an easier idea, and I would like to know if it would work or if it impossible: use Qt's slots and signals.
So, every thread I have comes from the same class, but passing different data to the Ctor. So the idea would be to create a slot and a signal inside that class, connect them and emit the signal passing an ID. Then, every thread's slot would be launched... or I may be completely wrong and the only slot launched would be the one from the very same thread which emited the signal.
Is this possible or not?
First of all, signal-slot connections are done between signals and slots in QObjects, not between threads. Well, a QThread is a QObject, but you really should not derive from a QThread. Do not derive from QThread and you'll be fine.
What you do is:
Get one or more QThreads started (not merely constructed). Those QThreads are just the base Qt classes, don't derive from them. A started raw QThread is blocked, waiting for an event to be posted to its event queue. The default implementation of QThread::run() calls QEventLoop::exec() (or an equivalent). Thus those threads, after starting, don't consume any CPU cycles.
Instantiate a bunch of QObjects. Do all the signal/slot connections as necessary.
Move those objects to one or more QThreads by calling moveToThread(QThread*) on them.
As you see, setting up signal slot connections is done in the usual manner and does not require any special attention. Qt does everything for you, including changing connection types from Qt::DirectConnection to Qt::QueuedConnection when you move the QObjects between threads.
Note that you must not call any methods on those QObjects directly, because you'll be doing so likely from a different thread, so all sorts of bad things will happen as the access is not serialized. You must do any of the below, and only that, in order from fastest to slowest. Note that while #3 is always faster than #4, you need to benchmark between #2 and #3 as it varies.
Post a custom event to the QObject, and handle it in the derived QObject's customEvent(QEvent*) method.
Use the signal-slot connections, and emit signals that got connected to the QObjects' slots.
Use QMetaMethod::invoke on a previously looked up method. The is faster than #4 since the method lookup is done only once in advance.
Use QMetaObject::invokeMethod.
Posting QEvents to QObjects is faster than using signal-slot invocations, because there are no copy constructors called and there's no marshalling done except directly by you upon construction of a QEvent.
Only if profiling/benchmarking shows that event posting is too slow you'd want to look at using QSharedMemory. Having an excessive number of QThreads is counterproductive, you should have probably not more than the number of CPU cores on the system. Using synchronization primitives such as mutexes or semaphores naively requires you to commit way too many threads. You definitely do not want to have one thread per connection! Qt already has an event queue mutex for each QObject, by using the event queue you already use that.
Signal and slot connections are done in run time, i.e. you are connecting specific instances of a class. You cannot emit a signal and "broadcast" it to every instance of your class. Signals between different threads is possible, but maintaining them could be a bit of a hassle (It's all explained pretty well in the documentation).
If I were you, I'd probably look into QSemaphore or QSharedMemory.
I need to find available network connections like eth,wlan,bluetooth. Does Qt emit any signals on detection of these access-points automatically? And also if more than 1 connection is available how would I know that which access point is used by system? And also if only 1 connection[apart form eth0] is present, for ex:WLAN Do we need to apply any additional settings for using ftp/htttp protocols?
Thanx
I think what you are looking for is QNetworkConfigurationManager which was added in Qt 4.7.
QNetworkConfigurationManager provides access to the network configurations known to the system and enables applications to detect the system capabilities (with regards to network sessions) at runtime.
It has signals for configurations being added and removed.
It can also trigger a scan with the updateConfigurations() slot (a signal will be emitted when complete):
Initiates an update of all configurations. This may be used to initiate WLAN scans or other time consuming updates which may be required to obtain the correct state for configurations.
You can set the connection a QNetworkAccessManager uses by calling QNetworkAccessManager::setConfiguration.
How many signals at maximum you can connect to a single slot? If more than one how you can do that? How many slots can you connect to a signal? If more than one how those slots will be executed? How a Qt Program/Application written for one platform (Symbian) can be ported/executed in another
You can easily connect more than one slot to a single signal using the usual way (QObject::connect), which are then called in order of connection when the signal is emitted.
Likewise can a single slot be connected to multiple signals, which is then called whenever one of those signals is emitted. You can even chain signals by connecting signals to signals, which are then emitted automatically whenever the source signal is emitted.
Such information can easily be gained by Qt's excellent documentation.
There may be a theoretical limit on the number of slots that can be connected to a signal, but this limit is surely beyond any practical relevance.
Although porting an application from an embedded system, like Symbian, to a desktop system, like Windows, may involve some additional issues, in general the porting of a Qt application to another platform just requires recompilation on/for that platform, assuming you didn't use any platform-dependent code in the rest of your application, which is usually not neccessary when using Qt.
you can connect as many slots to a signal as you wish. They will be executed in order in which they were connected.
Generally if you use only qt and no other platform dependent API, then recompiling it on target platform should be enough. Have no idea about Symbian though - sometimes Symbian seems to have a bit different rules.