-
Notifications
You must be signed in to change notification settings - Fork 361
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(playdate support) Missing pthread
APIs in ThreadUtil
#3877
Comments
pthread
APIs in ThreadUtil
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. |
Commix can still be used without SN multithreading, right? It'll just use threads internally? |
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. |
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 #if __has_include(<unistd.h>)
// System is posix-compliant
#else
// System is not posix-compliant
#endif |
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
):Cleaned up further:
What can we do about those? Would it make sense to hardcode
true
if multithreading is disabled (as I've been doing so far)?The text was updated successfully, but these errors were encountered: