[KDE/Mac] kshareddatacache_p.h forcibly avoids defining KSDC_THREAD_PROCESS_SHARED_SUPPORTED

[Ian Wadham]

Hi René,

On 09/01/2015, at 1:00 AM, René J.V. Bertin wrote:
> A remark about OS X not providing posix_fallocate led me to browse kshareddatacache_p.h (because posix_fallocate can be emulated), and therein I noticed
> 
> #if defined(_POSIX_THREAD_PROCESS_SHARED) && ((_POSIX_THREAD_PROCESS_SHARED == 0) || (_POSIX_THREAD_PROCESS_SHARED >= 200112L)) && !defined(__APPLE__)
> #include <pthread.h>
> #define KSDC_THREAD_PROCESS_SHARED_SUPPORTED 1
> #endif
> 
> which surprises me because even is OS X doesn't have timed mutex locking, it does have standard pthread mutexes.
> 
> Deactivating this when __APPLE__ is defined is not among the MacPorts patches, so where does it come from? Has anyone tested behaviour on OS X *with* KSDC_THREAD_PROCESS_SHARED_SUPPORTED defined?

Hmmmm, a blast from the past?… :-)

One of first KDE libs bugs I noticed on Apple OS X was:
    https://bugs.kde.org/show_bug.cgi?id=307652
    KSharedDataCache not working on Apple OS X 10.7.4 (Lion)
    Reported 2012-10-01

Michael Pyne (KSharedDataCache author) was very helpful, but
of course he did not have a Mac to test on and I did not have the
ability back then to build test versions of kdelibs.  It bubbled along
for a year or two and then the bug stopped happening in mid-2014,
so we closed the Bugzilla report.  Mysterious.

Re your issue, René, there is just the one use of that POSIX macro in KDE:
http://lxr.kde.org/search?_filestring=&_string=_POSIX_THREAD_PROCESS_SHARED&_casesensitive=1

Also see the following pages on KDE's repository browser:
https://projects.kde.org/projects/kde/kdelibs/repository/show/kdecore/util?rev=Active%2FTwo
https://projects.kde.org/projects/kde/kdelibs/repository/changes/kdecore/util/kshareddatacache_p.h?rev=Active%2FTwo
https://projects.kde.org/projects/kde/kdelibs/repository/diff/kdecore/util/kshareddatacache_p.h?rev=a33bbd7cb7d8863e46af066bb447f80fe601ca98&rev_to=15d04d6ea7cc45f70bfbd3e41b3cc4e6b15e367a

The "&& !defined(__APPLE__)" string was added on 2011-07-31,
a year or so before my bug report (see above), which answers your
question about where it comes from, but it cannot be what fixed the bug...

Weird.

Cheers, Ian W.