[Digikam-devel] [Bug 263272] Face Detection crashes on folders containing videos

[Andrew Coles]

https://bugs.kde.org/show_bug.cgi?id=263272





--- Comment #10 from Andrew Coles <andrew_coles yahoo co uk>  2011-01-22 12:42:19 ---
Created an attachment (id=56312)
 --> (http://bugs.kde.org/attachment.cgi?id=56312)
Patch to stop the same DynamicThread::run() function being called twice in
parallel

Okay, I think I've cracked this now.  In
DynamicThread::DynamicThreadPriv::run() it used to do:

takingThread();  // change threadRequested to 'false', allowing this
DynamicThreadPriv to be scheduled again

if (emitSignals)
{
    emit q->started();
}

if (transitionToRunning()) // if the DynamicThread was not running, mark it as
running (change the value of the variable state from Scheduled to Running)
{
    q->run(); // ...then actually call the run function
}

The problem seems to be the gap, between:

i) threadRequested being set to false
ii) state being changed from Scheduled set to Running.

On some executions of the program, between (i) and (ii) another copy of the
DynamicThreadPriv was scheduled and started.  Then, both managed to make the
transition to running, and q->run() was called twice at the same time on the
same q.

A solution, as far as I can tell, is to move the call to takingThread() lower
down:

if (emitSignals)
{
    emit q->started();
}

if (transitionToRunning())
{        
    takingThread();                
    q->run();
}
else
{
    takingThread();                
}

Now, there is no longer the (i)-(ii) gap discussed above: the variable
threadRequested is only set to false once the variable state records that the
thread is now running (or in the case of the else, once it has been safely
determined that the transition to running did not occur).

Patch attached: shall I commit or do you want to handle it?

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.