Unsafe accessor for ROOT_CONTEXT_P

[Alexei-Kornienko]

This is needed to properly setup ROOT_CONTEXT_P in case of shared library usage. Shared library has it's own copy of thread_locals so if generator was first initialized from main process and later accessed from shared library it causes UB due to ROOT_CONTEXT_P initialized incorrectly. This accessor allows to update pointer and ensure that both library thread locals and global thread locals point to the same object. See https://chao-tic.github.io/blog/2018/12/25/tls for reference

[Xudong-Huang]

Could you please supply a corrupted example for the case, so I can do some tests to try. The main usage of the crate is used as a normal static linked library. I never try for a shared library. Is it possible to init the thread_local things just in the loading of shared library that access them by it self instead of accessing from main thread?

[Alexei-Kornienko]

Could you please supply a corrupted example for the case, so I can do some tests to try.

Sure I'll try to do it on the weekend and provide a minimal example that would show the issue.

Is it possible to init the thread_local things just in the loading of shared library that access them by it self instead of accessing from main thread?

Not sure that it's possible. Library thread_local is isolated and cannot access the same variables from main process memory. For our use case we do the following: 1) we have a setup function in shared lib that is responsible for it's configuration 2) in main process we call get_root_context_p 3) load library 4) call setup function and pass this pointer to it 5) setup function call set_root_context_p with provided pointer

[Xudong-Huang]

I think ctor may help for the issue, you can just create a dummy generator and then drop it in the shared library before anything running, thus we don't need to change this crate.

[Alexei-Kornienko]

@Xudong-Huang not sure that I understand.. How dropping generator would help us to setup library root context correctly?

[Xudong-Huang]

drop is just release the resource, it's not important. But create a dummy generator in ctor would trigger the initialization in the shared library context.

[Alexei-Kornienko]

@Xudong-Huang I'm not sure that this will help. Problem is not with the fact that root context is not initialized. Problem is that there are 2 copies of root context initialized separately: 1) one created in main process memory and available through it thread locals 2) one created in library memory

Code compiled as dylib is unable to access context 1. That's what we are trying to fix by providing additional means to init context. Instead of creating context 2. we reuse reference to context 1.

[MageSlayer]

Any chance of this being merged?