Sorry, but the patch does not seem to be a good idea. Before the patch are mutexes by POSIX 1003.1c-1995, after the patch mutexes are ignored.

If I am not totally wrong, then on Linux the mutexes are ignored, too:

On Linux, just before the code in question:

PTHREAD_MUTEX_RECURSIVE is NOT set
PTHREAD_MUTEX_DEFAULT is NOT set
MUTEX_NONRECURSIVE_NP is NOT set
MUTEX_RECURSIVE_NP is NOT set

and this leads to:

Q_NORMAL_MUTEX_TYPE is NOT set
Q_RECURSIVE_MUTEX_TYPE is NOT set

... which works.
                  ^

On FreeBSD, just before the code in question:

PTHREAD_MUTEX_RECURSIVE is NOT set
PTHREAD_MUTEX_DEFAULT is set
MUTEX_NONRECURSIVE_NP is NOT set
MUTEX_RECURSIVE_NP is NOT set

and this leads to:

Q_NORMAL_MUTEX_TYPE is set
Q_RECURSIVE_MUTEX_TYPE is set

... which definitly is wrong and breaks.
With the patch applied, the code leads to:

Q_NORMAL_MUTEX_TYPE is NOT set
Q_RECURSIVE_MUTEX_TYPE is NOT set

... which works and is identical to the Linux settings.


So:
- neither Linux nor FreeBSD are handled as "POSIX 1003.1c-1995"
- neither Linux nor FreeBSD are handled as "POSIX 1003.4a". 
- both Linux and FreeBSD sould be handled equally as "Unknown mutex types - skip them". This is done for Linux, but not for FreeBSD.

The unpatched code forces FreeBSD to use recursive mutex, that it does not provide and which fails miserably. When my debugging was correct, the original FreeBSD code deadlocks at using a non-recursive mutex like a recursive mutex (which is the expected behaviour according to the man page).

So I assume I am correct in removing the special case for FreeBSD from the clause and let FreeBSD be handled equally to Linux.

(In reply to Nikolaus Klepp from comment #2)
> So:
> - neither Linux nor FreeBSD are handled as "POSIX 1003.1c-1995"
> - neither Linux nor FreeBSD are handled as "POSIX 1003.4a". 
> - both Linux and FreeBSD sould be handled equally as "Unknown mutex types -
> skip them". This is done for Linux, but not for FreeBSD.
> 
> The unpatched code forces FreeBSD to use recursive mutex, that it does not
> provide and which fails miserably. When my debugging was correct, the
> original FreeBSD code deadlocks at using a non-recursive mutex like a
> recursive mutex (which is the expected behaviour according to the man page).
> 
> So I assume I am correct in removing the special case for FreeBSD from the
> clause and let FreeBSD be handled equally to Linux.

Oh, well, I'll perform further research and also on Linux.

(In reply to Slávek Banko from comment #3)
> (In reply to Nikolaus Klepp from comment #2)
> > So:
> > - neither Linux nor FreeBSD are handled as "POSIX 1003.1c-1995"
> > - neither Linux nor FreeBSD are handled as "POSIX 1003.4a". 
> > - both Linux and FreeBSD sould be handled equally as "Unknown mutex types -
> > skip them". This is done for Linux, but not for FreeBSD.
> > 
> > The unpatched code forces FreeBSD to use recursive mutex, that it does not
> > provide and which fails miserably. When my debugging was correct, the
> > original FreeBSD code deadlocks at using a non-recursive mutex like a
> > recursive mutex (which is the expected behaviour according to the man page).
> > 
> > So I assume I am correct in removing the special case for FreeBSD from the
> > clause and let FreeBSD be handled equally to Linux.
> 
> Oh, well, I'll perform further research and also on Linux.

Okay, I can confirm your findings! On Linux mutexes are not used, and even if they are not used on FreeBSD, it brings a significant step forward in problems with threads. I congratulate you on successful result!

It seems that some problems remained - for example, after lock and unlock desktop, the thread in kdesktop process remains stuck - working hard. However, crucial problems seem to be solved.

Created attachment 2754 [details]
Not to force POSIX mutexes on FreeBSD

The same patch, just a little more polished => only removes enforcement for FreeBSD.

Which raises the question: is there any platform that runs TDE where are mutexes are used?

I have not done any investigation, just read through the bug report.

I find quite weird mutexes are not used at all. They must be in use, otherwise some functionities would not be able to work properly and surely some of the bugs I ran into in the past would not have happened.

I think those options about threads mean some specific behavior of mutexes are not used (for example recursive locking), but I strongly doubt it means that mutexes are completely ignored.

The two options Q_NORMAL_MUTEX_TYPE, Q_RECURSIVE_MUTEX_TYPE are probably TQt related, so if this makes some sort of difference in the way mutexes behaves, it means that there may be some sort of bug or incorrect code. We should investigate further when time is available.

Hope this help :-)

These parts of TDE use their mutexes on their own, but it's not used very often:

amarok/amarok/src/engine/helix
ktorrent
rosengarden
akode
kviewshell/plugins/libdjvu
kjs
arts/builder
mpeglib/example/yaf
xine_artsplugin
kopete/protocols/sms
akregator

experimental/tqtinterface/qt4

As far as I have seen, these parts do not care about specific pthread capabilities. I have never used any of these programs myself and never fell into other locking pits :-)

Is the patch in the repository yet?

(In reply to Nikolaus Klepp from comment #9)
> Is the patch in the repository yet?

No, the patch has not been pushed, because it seems that only masks the real problem that should be fixed. Hence we are doing further investigation.

I do not get the logic behind this: Are you going to enable mutex on Linux, too, and delay any further releases until the threading stuff is solved?  This does not make any sense to me. 

As pthread mutex from qmutex are not used / working on linux anyway, I do not see any reason to delay the TDE on BSD.

> I do not get the logic behind this:

The logic is quite simple. Slavek did some investigation and the result is that it seems that a problem with mutexes was introduced in TQt with R14. While it went unnoticed in linux, the problem was exposed in bsd because the options used for mutexes were different (thanks for the good work by the way).
While the proposed patch would aligned bsd and linux on the way the mutexes are used (and so it would probably work as a temporary work around), it is clear that something is wrong in TQt14 and we want to try to fix it properly rather than simply mask the problem away.

May I cite Eric S. Raymond: "Release early, release often"

14.0.0 was released a bit over 2 years ago. I do not have the feeling, that since then the missing mutex support did any harm to Linux users. On the other hand, this is a needless blocker for FreeBSD.

I decided as follows: We know that mutexes need repair. We know that attached patch only masks this problem as well as is for a long time masked on Linux. However, it is also certain that this code will be changed after repair the problem with mutexes. So now we can incorporate this patch because it will be properly fixed later.

Any objections?

sounds good to me. Just push the patch for the time being and leave the bug open. Longer term, we will try to fix mutex support properly.

Perfectly fine for me, too. My personal interest is getting TDE - especially kmail - working on FreeBSD.

For info the patch was merged long ago in commit https://mirror.git.trinitydesktop.org/gitea/TDE/tqt3/commit/9bbdfea568b8ae52b76aa8366612130403158320.

There is more work to do on threads support and this PR (https://mirror.git.trinitydesktop.org/gitea/TDE/tqt3/pulls/68) may help.

I am closing this specific bug since it pertains to the prodcon example.

Related to this bug, see also PR TDE/tqt3#68 (https://mirror.git.trinitydesktop.org/gitea/TDE/tqt3/pulls/68).