[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-commits-nodiffs] Revision eaaefa661c0da50ab2107ce15d9f508d8325
From: |
monotone |
Subject: |
[Monotone-commits-nodiffs] Revision eaaefa661c0da50ab2107ce15d9f508d83259347 |
Date: |
Sat, 13 Mar 2010 19:08:45 +0100 |
-----------------------------------------------------------------
Revision: eaaefa661c0da50ab2107ce15d9f508d83259347
Ancestor: 154a1d6e6680f1c64f2af4dc47d7848399516916
Author: address@hidden
Date: 02/01/2010 03:27:25 PM
Branch: net.venge.monotone.guitone
Modified files:
src/monotone/MonotoneManager.cpp
ChangeLog:
* we had a race condition on Linux in ::stopAllWorkspaceThreads(): while we
signal stopped() from the thread just before we return from run(), this signal
is executed asynchronously, thus a QThread::finish() signal comes right after
it and lets other threads return immediately from QThread::wait(). While the
stopped() slot is still not executed, we immediately trying to query data again
and got the old, about to be stopped thread (and now also really stopped
thread) as "new" thread, which blocks task execution since it won't ever be
started. To make a long story short, we now directly removing the thread's data
in the same parent thread right after we return from QThread::abort() and relax
the check in MonotoneManager::removeThread() for a non-existing thread id
monotone --db={your.database} diff
--revision=154a1d6e6680f1c64f2af4dc47d7848399516916
--revision=eaaefa661c0da50ab2107ce15d9f508d83259347
----------------------------------------------------------------------
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Monotone-commits-nodiffs] Revision eaaefa661c0da50ab2107ce15d9f508d83259347,
monotone <=