Robustness of Qt based projects

**wysota** · 23rd April 2009, 20:59

Originally Posted by Sheng

Thanks, is there any robustness testing report? for example, how about 100 people connect to the server from nxclient and use KDE simultaneously? just curious.

This is not robustness, this is scalability. And Qt has nothing to do with that by the way. Could you say what you need this information for anyway?

**Sheng** · 23rd April 2009, 22:23

Originally Posted by wysota

This is not robustness, this is scalability. And Qt has nothing to do with that by the way. Could you say what you need this information for anyway?

Just want to know how Qt application works with heavy load of signals and threads. Our application used to work fine for several days then crashes, it can happen in second day or in 10th day. Now we decreased the load of signals and threads and improved the Controller, it can work for long time.

**wysota** · 23rd April 2009, 23:19

Having too many signals emitted can slow down your application but not crash it. There has to be something wrong in your application logic. What did the debugger say? Where did the crash occur? Maybe you simply have a memory leak and you run out of resources?

**bnolsen** · 25th April 2009, 16:29

You asked all the wrong questions.
Robustness starts with design and choice of hardware/tools, not a toolkit.

Based on my little experience with hydroelectric & natural gas monitoring
#1 - if your running windows you've already lost (definitely true pre vista64...I have suspicion server 2008 x64 is also not robust).
#2 - your primary systems should coded leveraging the OS itself -- no GUI components. Cross platform is nice but you trade robustness. With Qt this definitely is always a moving target (and partly why my company dumped Qt).
#3 - Core robust systems should not be gui-ized. GUI should only interact with/reflect those system states using some communication mechanism.