On Wed, 21 Sep 2005, Angus Leeming wrote:
Anyway, trying to unlock a mutex that is already unlocked will result in
undefined behaviour when using POSIX threads. See, for example Section 3.3.2
"Locking and unlocking a mutex" of "Programming with POSIX threads" by David
R Butenhof.
So, I'm not going to apply your fix; sorry.
I was also told in http://thread.gmane.org/gmane.editors.lyx.devel/46629
that "The problem is that QApplication::locked() is lying to you. That's a
Qt problem, so the solution must be: fix Qt on NetBSD."
So I filed a bug report with trolltech. They gave me some sample code to
run and I did several tests. This was their reply:
Right. You are sure that it's the destruction of the QApplication mutex
that's causing this? Anyway, I'm not sure I see the reason why they're
trying to unlock the QApplication mutex, you're supposed to lock it
from other threads than the thread where QApplication was created, and
you're not allowed to unlock a mutex from a thread that did not
previously lock it. I also noticed the following paragraph from the
QMutex::locked() documentation that could be related:
Warning: Due to different implementations of recursive mutexes on the
supported platforms, calling this function from the same thread that
previously locked the mutex will give undefined results.
Does this help at all?
According to the test I was given by trolltech to run on NetBSD, it
behaved correctly.
I will be glad to test other ideas.
Thanks,
Jeremy C. Reed
