Semaphores and condition variables.

[Apprentice-Alchemist]

• hxcpp (Semaphores and condition variables. hxcpp#976)
• C#
• Java/Jvm
• Python
• Eval
• Hashlink (Semaphores and condition variables. hashlink#495)

Since neko is deprecated I have not implemented these for neko.

[RealyUniqueName]

Nice!
Pls, fix building so we can check CI.

[Apprentice-Alchemist]

Please don't do this, there are some implications related to packaging that we would like to avoid.

Changes to the ocaml version have been reverted.
Using luv to implement semaphores and condition variables seems to work.

[RealyUniqueName]

I think luv's synchronization primitives require explicit calls to destroy methods for cleanups.

[ncannasse]

I'm curious about the efficiency of these VS implementing them on top of Lock/Mutex :)

[Apprentice-Alchemist]

Lock is already implemented using a semaphore on many targets.
So to implement a semaphore, you'd end up using a semaphore + an extra counter + a mutex to protect that counter.
That sounds less efficient that using a semaphore directly.

[Simn]

Sorry for the delay! I've merged the hxcpp PR, could you update this one so CI runs?

Edit: Uhm, wrong PR, sorry!

[Simn]

Now my last comment is accurate, so could you push again? I still don't know why I can't restart CI on this one.

[Apprentice-Alchemist]

windows64-test (cpp) failure: Turns out hxcpp already sets the HXCPP_WINXP_COMPAT by default.
Simplest fix (in my opinion) is to turn that off: HaxeFoundation/hxcpp#984
windows-build failure: no idea, it's not showing any logs.

[Simn]

Had to restart CI again because CI / linux-arm64 (pull_request) was hanging. Let's see if this finally turns green now...

[Simn]

Whatever, I'll just merge this!