My program has two states and it can switch between them for some reasons. In these states the program needs to receive different signals, which means it has to connect and disconnect certain signals during the run.
How bad is such approach?
It's a fine approach, I've used it before without issues. Depending on what you're actually doing a QSignalMapper might be of use for you.
Related
Is is possible to have ebpf program generate event, for example packet counter reached a predefined threshold value and ebpf would generate some notification/event to user, something similar to what netlink provides.
I see that currently the only way to signal this event/state is via maps which can be polled by the user application.
No, there isn't a way currently to signal userspace or other programs without polling maps.
This has been briefly discussed on the iovisor-dev mailing list before. If you have a use case for this, you might try to bring it on the mailing list.
This question is not directly about programming, but I hope that it still fits here: When programming with Qt I have the problem that after some times my subclasses are getting extremely large which leads to a lot of signals and slots in each class I have to connect later. Therefore I was wondering if there is a simple possibility to keep track of all the signals and slots, for example to tell me if I forgot to connect a signal, or to show me all connections of one signal if it is connected more than once. Is there a tool or a function in Qt for that, or should I rather stay with pen & paper for keeping track of them?
Conan is a C++ library that provides run-time introspection of object
hierarchies, object inheritance, signal/slot connections, and signal
emissions.
GammaRay is another advanced analyser which can show signals/slots.
I'm just curious how much overhead I might incur in a program that... abuses signals and slots ridiculously. Our app has almost everything connected via signals and slots. We've replaced calling functions with signals and slots for general data flow so we're passing data along a crazy chain.
I've already shown some concern on the design on this to see how easy it will be to debug/follow later but I'm curious about the performance we'll see. We have a small app now, but I imagine we'll see some issues as the program grows out of control.
Just to give a small idea of how much we are abusing signals, we are emiting a signal to call a logging function
I am not familar with WINAPI, and I am looking for a way to replace WaitForMultipleObjects used in one example I'm porting to Qt by anything using Qt only. Is it possible?
EDIT: (Providing more information as requested in comments)
A 3rd party API provides an array of events:
HANDLE m_hEv[MAX_EV];
In an endles-loop of a thread, the program waits for the events like this:
WaitForMultipleObjects(m_EvMax, m_hEv, FALSE ,INFINITE )
The HANDLE type seems to be void*.
So I wonder, if any Qt class could observe m_hEv for changes and unlock thread execution.
There is no simple way of porting WaitForMultipleObjects outside WinAPI. WinAPI has an "advantage" of that all lockable resources (sockets, files, processes) provide the same generic non-typesafe HANDLE, which is your void*. Unlike other platforms which have different ways of locking and signalling per the type of resource, the event handling in WinAPI is largely independent of the resources. Then a generic function like WaitForMultipleObjects can exist, which doesn't need to care who produced the HANDLEs. So you'll have to understand what the code is trying to do and mimic it differently per scenario.
The biggest difference is in WaitForMultipleObjects third parameter, which is FALSE in your case. Which means that the it will exit waiting as soon as any single event of the waiting array will happen. That is the easier scenario and can be replaced with a QWaitCondition.
Instead of m_hEv, you will pass a QWaitCondition* into the code which signals the event (most probably via WinAPI SetEvent(m_hEv[x]))
Instead of WaitForMultipleObjects, do QWaitCondition::wait().
Instead of SetEvent(), do QWaitCondition::wakeOne().
Would the third parameter be TRUE, then the WinAPI code waits until ALL m_hEv events are signalled. The established name for such functionality is a synchronization barrier and it can be simulated with QEventCondition too, but does not come out of the Qt box. I never needed to do any myself, but SO has some ideas how to do it:
Qt synchronization barrier?
WaitForMultipleObjects is a kind of generic function that works with many things: threads, processes, mutexes, etc. Qt is an OOP library where every class exposes the operations it supports. So the equivalent operation in Qt depends on what class you're using. For example, with threads, use QThread::wait. With mutexes, use QMutex::lock.
I'm currently writing a programme which has a function to hash a number of files in the background. I've read the Qt4 documentation a number of times over and I still can't really figure out which threading option is best for this.
http://doc.qt.io/qt-5/thread-basics.html
There's really no need to update the GUI when it's done with each file, I just don't wish to block the GUI and I really only need a single signal/slot connection upon completion. I'm thinking of extending QThread for a hashing thread. Does this sound reasonable/right?
I have this article bookmarked as it nicely illustrates the use of QThread and highlights some common misconceptions about it. Sample code available, which runs without blocking the GUI. Sample is hosted on RapidShare, but they seem to have implemented some sort of timed waiting period since I last used it.
This sounds like a good place to use the QtConcurrent::map() function. The map function can apply the same operation to a container of objects, in your case, files. Once you start the map function, you can create a QFutureWatcher and connect to its finished signal to be notified when all of the work is done.