Qt Plugins and Callbacks

[abernat]

I'm working on an application that communicates with a digital i/o card to communicate with some lab equipment. I'd like to write the actual device interface as a plug-in so it can be changed easily if the hardware changes. Part of this involves collecting information from the hardware to pass back to the application. Since some of the hardware involved will cause an interrupt when data is ready, I don't want to build a polling system into the main application--if there is a poller anywhere in software, I'd rather it be in the plug-in and have the main application agnostic. So, while I'm still in the design phase, I'm positing this question so as to come up with the best approach:

Is there any problem with passing a callback to a method in a dynamically loaded Qt plugin? It will most likely be a C++ static method.

Thanks,

Kenny

[abernat]

Just for clarification:

What I was thinking is that I'd have a setCallback function in the plugin that would accept a functor for a static method in the main application, which would then be invoked by the plugin when data was ready.

[jpn]

How about emitting a signal?

[abernat]

A signal might work, and I'll go that route if needed. Some of our equipment has a fairly high sampling rate though (up to 40000 Hz) , so I'm looking for a solution that's both quick and clean.

[wysota]

There is nothing more clean in a Qt based application than Qt signals.

[abernat]

I realize signals are clean. It's the performance issue I'm concerned about. While this isn't a real-time system, the communication between the plugin and the rest of the application really needs to be as fast as possible, which is why I'd like to do a callback. And as there will only ever be one object in the main application that's ever receiving data from the plugin, the benefits of using a signal may be outweighed by the performance hit I take.

[talk2amulya]

why would there be a performance issue as signal-slot mechanism is in effect like a callback mechanism itself!

signal -> slot : condition -> callback function

QT cant possibly introduce any performance hit by introducing signal-slot or most of their applications would die on PCs cuz of the amount of signal-slot employed in them. Best would be u try it out and remove your doubts

[abernat]

There's much more to signals and slots than simply being callbacks. There's no if statement on the plug-in side to determine what callback to invoke--simply a function in the main application that's called when data is ready. With signals and slots, there are lookups and data marshalling involved, so there is overhead incurred. For most applications it's not enough to be noticed by a user, but as I said earlier, I could have 40,000 (maybe even in the 500,000 range) function invocations per second. This is a data collection application in a science lab, so performance matters here. Now perhaps if there are benchmarks demonstrating signal/slot efficiency I'll be convinced. Until then, though, I'm most concerned with making everything as quickly as possible, as we have a large amount of data to collect and process.

[wysota]

500000 invokations per second? Forget it, it's not going to happen. There are at most 1000 timer interrupts per second in the system. 500k signals from the driver would be 500 calls per one timer quantum. I don't think even a real time system could guarantee that. Let's go further - 500k ticks per second (5E+5) on a 1GHz computer (1E+9) would mean ~E+4 cpu cycles per one invocation. That's about how long a context switch takes (actually it's a few thousand cycles).

Besides if the system would even somehow manage to deliver so many interrupts you wouldn't be able to do anything with them. 40k per second is 40 events per millisecond, I don't think any system would live with even that especially if you want it to remain responsive. I suggest you handle 100 calls per second. Unless you are driving a live nanite in a bloodstream this will be enough for almost anything. And signals will have no problem handling that, especially if you emit them only once in a while (if a signal is pending, there is no point in emitting another one, right?).