QTableWidget Design & Thread Safety Question

**bpetty** · 24th March 2008, 22:33

Hey guys,

I am writing a simple app that tests various ODBC calls and SQL statements to analyze performance. It can spawn many threads... each thread, for example, could run a query over and over again, gathering statistical data for the run.

I have a QTableWidget that I am wanting to use to view this data. Each threads gets its own row in the table.

I was wonder if it was safe to have each thread update its own row. I think it would be safe since it is essentially a node based container and I am only updating the values of existing nodes.

Would it be better if I have a timer on my main thread that polls data from my worker threads so that it would be responsible for updating the QTableWidget instead of each thread updating their own row?

**Equilibrium** · 25th March 2008, 08:37

use post event

**jacek** · 25th March 2008, 18:37

or a signal and a queued connection.

**bpetty** · 27th March 2008, 23:57

I am just curious... is it a bad idea for different threads to modify data in a QTableWidget's QTableWidgetItem if each thread never accesses another threads QTWI?

I have a QTimer that is running, I was thinking that is what I could use to repaint the table.
It just sounds like this is the most efficient way in terms of CPU load. It would give the user a chance to specify a refresh increment too. You would lose a nice looking asynchronous effect, but other than that...

**jacek** · 28th March 2008, 00:09

Originally Posted by bpetty

I am just curious... is it a bad idea for different threads to modify data in a QTableWidget's QTableWidgetItem if each thread never accesses another threads QTWI?

It's a Very Bad Idea(tm). All widgets belong to the GUI thread and it's very jealous about it.

Originally Posted by bpetty

I have a QTimer that is running, I was thinking that is what I could use to repaint the table.

You can use QTimer to poll the threads or you can make threads send signals/event when data changes. Everything depends on the number of updates per second. If thread will send more than 25 signals per second the polling aproach might be more efficient. On other hand threads can send only changed data, while with polling approach you will have to check all the data.