[cpp] Typed Thread and TLS#12885
Open
Aidan63 wants to merge 2 commits intoHaxeFoundation:developmentfrom
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
HaxeFoundation/hxcpp#1336
This is much the same as my other threading related updates, adding a typed api for threads and thread local storage on the cpp side and exposing them in haxe. The main changes are.
hx::thread::Threadapi for spawning, current thread, etc. This now supports the thread name setting which was recently added, although this is only implemented on Windows.Important note on the Windows implementation, it uses the modern
GetThreadDescriptionandSetThreadDescriptionWin32 api which was added in Windows 10. So this does add a Windows 10 hard dependency to hxcpp. I'm not fussed about this but it's probably worth mentioning in case anyone is.There is also an implementation difference here which is also worth noting. In the old implementation hxcpp would immediately detach the thread, but we keep the thread attached now until the haxe object is finalised since you can't set the description of a detached thread. This was fine on Windows, but the hxcpp "haxe" tests (not haxe repo tests) on 32bit Linux were failing due to a "lack of resources" (creating too many threads). One of the tests spins up a bunch of threads and seems to be hitting a OS limit now that threads aren't detached until finalisation, since only name setting is implemented on Windows I've made it eagerly detach threads on other OS'.
hx::thread::ThreadLocalapi for thread local storage.This implementation has changed slightly, instead of using an ever growing counter, TLS objects return their slot ID when finalised so they can be recycled. This should hopefully help reduce the TLS array from constantly growing in long lived programs.
ScratchapiSomething I've wanted for a while is to be able to create short lived (tied to the current scope) non GC memory for various introp cases (e.g. encoding haxe strings or arrays before passing to native code). Normally you would do this with c arrays or
std::arraybut the constant / compile time size requirement makes this a pain in haxe.The scratch api provides this sort of functionality, each thread contains a buffer which the scratch api simply bump allocates out of. Since this uses the
cpp.Marshal.Viewtype and stack only flags these scratch allocations can't escape the current thread so are safe to be reference counted.For example the following is a code snipped which parses a date out of a string with zero GC allocations (and without needing to do all the manual string indexing you'd need to do).
Like the others the hxcpp side needs to be merged before the cpp tests on the haxe side will pass.