PDA

View Full Version : Using non-GUI Qt in a simulator (with multiple instances, simulated time, etc.)



qtdan
1st February 2008, 19:00
Hi,

I'm interested in using Qt for a non-GUI core networking daemon for an application I'm creating. The daemon is quite complex and consists of many "components" which accept inputs and produce outputs. This style of design is well-suited to the slots and signals mechanism of Qt.

I have read through a lot of the Qt examples and documentation and it looks like a great dev. environment. However, I have some reservations which I hope somebody here can allay. Please let me know if these questions are silly, or are a bit confusing, and I'll try to restate them. :)

I need to be able to run the bulk of my deployable code in a simulator (OMNeT++), using simulated time and with multiple instances of the daemon connected via a virtual network. This all needs to run in a single process, which provides its own future event queue and main() function to direct the simulation.

* Does the QCoreApplication model lend itself to multiple instances of my daemon code all running in the same event loop (i.e., in one thread)?
* Would it be easy to modify the event loops used in Qt to operate according to a virtual time provided by the simulator? (I want to run the simulation at much faster than real-time.) Or are these event loops entirely divorced from time (i.e., just queues, not future event queues)?
* If I use mechanisms such as QTimers, can they operate on this virtual time rather than actual system time? Is this the only Qt class that relies on time?
* Would it be easy to then take (essentially) the same code and have it use separate threads for each component when I actually deploy my daemon in the real world?

These sorts of problems are fairly easily solved if I roll my own event loops, etc. (which I have done for a C# prototype), but I'd like to know how much of Qt I could use before having to roll my own in C++.

Thanks,
Dan

wysota
1st February 2008, 19:55
* Does the QCoreApplication model lend itself to multiple instances of my daemon code all running in the same event loop (i.e., in one thread)?
Depends what you mean by "daemon code". If you mean multiple event queues then no, but if you mean "handling events for multiple object independently" then yes.


* Would it be easy to modify the event loops used in Qt to operate according to a virtual time provided by the simulator? (I want to run the simulation at much faster than real-time.) Or are these event loops entirely divorced from time (i.e., just queues, not future event queues)?
You can implement your own event loop if you want, so a general answer is yes. On Unix Qt uses glib event loop or a classic unix event dispatcher - if you know how to interface them, you have everything ready. If not, you'll have to write some code, I guess...


* If I use mechanisms such as QTimers, can they operate on this virtual time rather than actual system time?
That I doubt. Qt uses system timer support to achieve its goals. If you modify Qt's source code or place it in a properly prepared operating system then maybe you could control it the way you want.


Is this the only Qt class that relies on time?
No. QTime is probably the one that may cause you trouble.


* Would it be easy to then take (essentially) the same code and have it use separate threads for each component when I actually deploy my daemon in the real world?

Depends what the code does. Probably yes.