Paul1892
9th July 2010, 14:26
Hi Everyone
I have a QListView descendant which is updated when messages come in to our application over our network. A customer has an issue whereby at times when the network traffic is excessively high the CPU time sky rockets and our main application is unable to process messages ie the UI fails to respond. This is the very time they need to use the UI but are unable to until the messages stop.
My solution works well, this was to defer the messages onto a list, have the list monitored by a Win32 Thread, and when the message count is > 0 fire off an event from the thread that causes the event handler to update the QListView within the context of the monitoring thread but allowing that thread to sleep between message updates. All handling of data is done within a critical section as is the actual call to update the QListView.
As I say this works great however I have since read in the QT Assistant and in a QT white paper on multithreading that "While writing thread-enabled GUI applications with Qt, all GUI-related operations must be performed in the main thread only". My solution has performed beautifully through intensive testing but we are now consequently concerned that we are doing something that the documentation tells us not to do!
Does anybody have any comments on this or is there another way I can achieve my goal of updating the QListView under intense network traffic without locking the UI? This is a Win32 application running on XP.
Thanks in advance.
Paul
I have a QListView descendant which is updated when messages come in to our application over our network. A customer has an issue whereby at times when the network traffic is excessively high the CPU time sky rockets and our main application is unable to process messages ie the UI fails to respond. This is the very time they need to use the UI but are unable to until the messages stop.
My solution works well, this was to defer the messages onto a list, have the list monitored by a Win32 Thread, and when the message count is > 0 fire off an event from the thread that causes the event handler to update the QListView within the context of the monitoring thread but allowing that thread to sleep between message updates. All handling of data is done within a critical section as is the actual call to update the QListView.
As I say this works great however I have since read in the QT Assistant and in a QT white paper on multithreading that "While writing thread-enabled GUI applications with Qt, all GUI-related operations must be performed in the main thread only". My solution has performed beautifully through intensive testing but we are now consequently concerned that we are doing something that the documentation tells us not to do!
Does anybody have any comments on this or is there another way I can achieve my goal of updating the QListView under intense network traffic without locking the UI? This is a Win32 application running on XP.
Thanks in advance.
Paul