(playdate support) Missing pthread APIs in ThreadUtil

[kubukoz]

Ref: #3876

In nativelib/src/main/resources/scala-native/gc/shared/ThreadUtil.c, there's some usage of APIs that aren't available on Playdate (pthread):

ld: libroot.a(dependencies_nativelib_native0.5_3-0_scala-native_gc_shared_ThreadUtil.c.o): in function `mutex_init':
(...)nativelib_native0.5_3-0/scala-native/gc/shared/ThreadUtil.c:56:(.text.mutex_init+0x14): undefined reference to `pthread_mutexattr_init'
ld: (...)nativelib_native0.5_3-0/scala-native/gc/shared/ThreadUtil.c:57:(.text.mutex_init+0x1c): undefined reference to `pthread_mutexattr_settype'
ld: (...)nativelib_native0.5_3-0/scala-native/gc/shared/ThreadUtil.c:58:(.text.mutex_init+0x24): undefined reference to `pthread_mutex_init'
ld: libroot.a(dependencies_nativelib_native0.5_3-0_scala-native_gc_shared_ThreadUtil.c.o): in function `mutex_lock':
(...)nativelib_native0.5_3-0/scala-native/gc/shared/ThreadUtil.c:67:(.text.mutex_lock+0x2): undefined reference to `pthread_mutex_lock'
ld: libroot.a(dependencies_nativelib_native0.5_3-0_scala-native_gc_shared_ThreadUtil.c.o): in function `mutex_unlock':
(...)nativelib_native0.5_3-0/scala-native/gc/shared/ThreadUtil.c:85:(.text.mutex_unlock+0x2): undefined reference to `pthread_mutex_unlock'

Cleaned up further:

undefined reference to `pthread_mutexattr_init'
undefined reference to `pthread_mutexattr_settype'
undefined reference to `pthread_mutex_init'
undefined reference to `pthread_mutex_lock'
undefined reference to `pthread_mutex_unlock'

What can we do about those? Would it make sense to hardcode true if multithreading is disabled (as I've been doing so far)?

[WojciechMazur]

It makes sense to allow mocking it in Immix GC, as its only used to synchronise threads (we might actually guard for usages here using preprocessor), but in case of Commix we should stop compilation early with error about unsupported platform - that GC is built-up on threads assumptions.

[kubukoz]

Commix can still be used without SN multithreading, right? It'll just use threads internally?

[ekrich]

It used to be fine, that is how single threaded performance got really good on the benchmarks. Immix couldn't do the trick. That is how I remember it anyway.

[ekrich]

I found this on SOF. https://stackoverflow.com/questions/11350878/how-can-i-determine-if-the-operating-system-is-posix-in-c

In C++17 (and C as a GCC and clang extension), there is now a __has_include operator that can be used in #if directives. This means that you can check for posix compliance like this:

#if __has_include(<unistd.h>)
    // System is posix-compliant
#else
    // System is not posix-compliant
#endif