Prevent registering static FASTTLS with multiple libjulias #50083
Conversation
|
I wonder how can we test this? Maybe a small dylib that just tries to access the TLS? |
|
There is also a bit of a design challenge here. If we have two libjulia's loaded who owns the TLS? It presumably is the outer one. But if the linjulia is of an older (or newer) version it may make assumptions about the data layout behind the TLS. Those assumptions are baked into the generated code. If we load two libjulia's are we running two GCs? I suspect we need to limit it to the same version of Julia (if we expect to run any code within it) or indeed setup a separate TLS (but then our fast TLS for generated code is gonna bit a bit iffy) |
This PR makes it so that the first one loaded will get the fast local-exec TLS, and the other will use its embedding fallback TLS (tied to a static local in each copy of libjulia)
We are - they are intended to be as isolated as possible for now, with only C-style objects passing between them |
9c57124
to
27373cd
Compare
When there are multiple copies of libjulia present in the application,
they can both end up trying to use the same static fast tls storage.
The alternative options I considered for this were:
- Add `jl_options.use_static_fasttls` and update PackageCompiler.jl to
set the flag to FALSE
- Use `dlvsym` in the CLI loader and attach to the exported
jl_pgcstack_static symbols `__attribute__((symver(...)))`
The second approach is not available on musl, but the first one seems
like the ideal way to handle this long-term.
27373cd
to
e1c0d83
Compare
From Jameson: > apparently on Windows, the _Atomic x syntax means something slightly different and is not correctly implemented Co-authored-by: Jameson Nash <[email protected]>
When there are multiple copies of libjulia present in the application, they can both end up trying to use the same static fast tls storage.
The alternative change here would be to add
jl_options.use_static_fasttlsand modify PackageCompiler.jl to set the flag tofalse.However, that requires injecting a
#definein PackageCompiler depending on the presence of the new flag, or starting to assign version numbers tojl_options_t