Bug #3735
closedwtwithqt: triggerUpdate() causes rendering outside the Qt-Thread-Context
0%
Description
This Bug is descibed in http://redmine.emweb.be/boards/2/topics/10075?r=10238#message-10238 and applies to 3.3.4rc1 running on Windows7 with Visual Studio 2013
When I do a Wt::WAbstractItemModel::layoutChanged().emit() followed by an Wt::WApplication::triggerUpdate() in the context of a Wt::WServer::post(), then the resulting rendering is done directly from a Wt-threadpool-context, not by the QtThread-Context of Wt::WQApplication.
In the attached TestCase there is a model created in Wt::WQApplication::create() which asserts, when one of its 'render-functions' are called from another thread as the one which created it.
When the call to triggerUpdate() in DemoModel.cpp (line 183), is enabled then these asserts do fire.
Files
Updated by Kai Scherrer almost 10 years ago
Meanwhile I've teset this on a Debian Wheezy machine and the testcase behaves the same here.
I've attached an updated version which builds with Debian's gcc 4.7.2. There is also a shell script inside (make.sh) which builds the testdemo including the wtwithqt-example. If you use this you need to change the pathes in the first 8 lines so that they apply to your build setup.
To see the asserts you need to remove the -DNDEBUG in line 3.
Updated by Koen Deforche almost 10 years ago
- Status changed from New to InProgress
- Assignee set to Koen Deforche
Hey,
Thanks for the test case. I indeed believe that this wasn't implemented yet in the wtwithqt lib (and/or perhaps this needs some changes in Wt as well).
Koen
Updated by Koen Deforche almost 10 years ago
- Status changed from InProgress to Resolved
- Target version set to 3.3.4
Still needs to be pushed to the repo.
Updated by Koen Deforche almost 10 years ago
- Status changed from Resolved to Closed