Does not seem to recover when it happens, requiring the Lime app to be force closed. Some kind of threading issue that is affecting HashLink on Windows only (macOS and Linux are fine, and other sys targets are fine).
Fixed by passing SINGLE_THREADED to ThreadPool constructor using #if (windows && hl)
Example:
<config:air tsa="http://timestamp.digicert.com"/>
Required to workaround "Could not generate timestamp: Connection reset" error from adt with default timestamp URL.
We're currently using a version of hxcpp from GitHub instead of from Haxelib for macOS ARM64 support. Let's just use that version for all jobs, for consistency. Whenever hxcpp finally gets update on Haxelib, we'll switch to that version.
Needed for macOS when using Xcode 16 and clang 16. This version of clang produces errors like this when compiling harfbuzz:
cast from 'void (*)(FT_Face)' (aka 'void (*)(FT_FaceRec_ *)') to 'FT_Generic_Finalizer' (aka 'void (*)(void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
This is the minimum version of harfbuzz that fixes the errors. We could certainly consider upgrading further (current release is 10.0.1 at the time of this commit).
These were added for drop-in compatibility with `BackgroundWorker`, but we might not need that level of compatibility. We can discuss adding these back later if there's demand.
It looks like we'll want to take `BackgroundWorker` in a different direction, so for the moment it's safest not to change anything about it. That way, there's only one historical version to maintain backwards compatibility with.
`__activeThreads` and `__idleThreads` only need to be allocated for multi-threaded pools. Plus, there's no benefit to using a `List` here; we only add to and remove from the end.
And finally, checking `event.job == null` instead of `isOfType()` is faster and avoids an issue in HTML5. Sadly it is less safe, so we might need to revisit it eventually.
