Zeta

Ah, figured it out. Starting in MbedTLS 3.6 `MBEDTLS_SSL_PROTO_TLS1_3` is enabled by default. The TLS 1.3 code uses PSA Crypto, which requires `psa_crypto_init` to be called before using any mbedtls...

> it requires a variant of homebrew that is installed with x86_64 as well, while I have other projects which requires homebrew arm64. You should be able to have both...

Good enough to merge, not good enough to enable by default. Linux/macOS with an install in `/usr/local/` work, other setups (eg when installed from Homebrew or a Linux package manager)...

Other setups (including Windows) now work too.

If the goal is purely performance I'd suggest something like `@:generic(primitivesOnly)`. That way platform-specific primitive types (eg `java.Int16`) can also be handled without the user having to worry about that.

This is entirely expected, `EReg.match` modifies internal state and is therefore not thread safe. You should either create a new regex on each thread or use a mutex. I don't...

Bisected the mandelbrot performance regression to https://github.com/HaxeFoundation/hashlink/commit/9289265cbb6418e6ae4aae6e80063679d62ab032 (added gc parallel marking) When testing on latest master, setting `GC_MAX_MARK_THREADS` to 1 makes it perform well again, whereas setting `GC_MAX_MARK_THREADS` to anything...

You could register/unregister the thread around each function?

Eval also has atomics now (https://github.com/HaxeFoundation/haxe/pull/12275), so out of the targets with threading that just leaves Neko and Python. Neko could have native support, that's just a question of adapting...

Here's implementations for both Neko and Python: - Python: https://github.com/Apprentice-Alchemist/haxe-python-atomic and https://github.com/Apprentice-Alchemist/haxe/tree/python-atomics - Neko: https://github.com/Apprentice-Alchemist/neko/tree/atomics and https://github.com/Apprentice-Alchemist/haxe/tree/neko-atomic