ThreadWeaver unit tests (Re: [PATCH] Fix ThreadWeaver JobCollection deletion race)
mirko at kdab.net
Mon Jul 14 07:59:05 BST 2008
I have to look into this. The tests used to run :-)
Generally, it is a misconception that Jobs can be safely deleted when they
emitted their done() signal. As long as a reference to an object is held in
some other place, this is generally bad practise.
I will debug.
On Wednesday 02 July 2008 21:05:10 you wrote:
> On Wednesday 26 March 2008, Robert Knight wrote:
> > [...]
> > I suggest making it explicit that a Job can be safely deleted (with
> > respect to ThreadWeaver itself) as soon as it emits its done(Job*)
> > signal. With the attached patch ThreadWeaver conforms to these
> > semantics.
> This patch enabled the unit tests for ThreadWeaver. However they don't
> properly here:
> ********* Start testing of JobTests *********
> Config: Using QTest library 4.4.0, Qt 4.4.0
> PASS : JobTests::initTestCase()
> PASS : JobTests::WeaverLazyThreadCreationTest()
> PASS : JobTests::SimpleJobTest()
> PASS : JobTests::SimpleJobCollectionTest()
> PASS : JobTests::EmptyJobCollectionTest()
> PASS : JobTests::ShortJobSequenceTest()
> PASS : JobTests::EmptyJobSequenceTest()
> PASS : JobTests::QueueAndDequeueSequenceTest()
> PASS : JobTests::RecursiveQueueAndDequeueSequenceTest()
> PASS : JobTests::QueueAndDequeueAllSequenceTest()
> PASS : JobTests::RecursiveQueueAndDequeueAllSequenceTest()
> PASS : JobTests::MassiveJobSequenceTest()
> ... and then nothing happens. All threads are waiting on a wait condition.
> This obviously makes "make test" hang indefinitely.
> Can someone (Mirko?) have a look at it -- or if time is lacking, give me
> hints about what the problem might be?
More information about the kde-core-devel