https://youtu.be/-dxCaM4GOqs
Definition:
Dynamic linking, opposed to static linking form a physical aspect of a program relocation is done at load time.
Dynamic loading ask for additional functionalities often involve library discovery relocation is done at run time maybe capable of 'unloading'.
in C++, object do not relocate but functions do.
Or to be precise, C/Assembly function kind do relocate, thus Golang could have dynamic growing stack size which relocate function at runtime.
After dlopen, unloading is often avoided due to this makes function having a 'lifetime'.
e.g. musl's dlcose is a noop. (complicating thread-local storage(TLS) implementation if library may unload)
Can objects from a library outlive the library?
Library lifetime realized in C++
- When loading a library, init. objects with static storage duration at namespace scope.
- When unloading a library, destruct objects with static storage duration.
- Loaded libraries are reference counted.
Interaction with thread_local
- When a thread starts, init. objects with thread storage duration at namespace scope.
- When a thread exits, destruct objects with thread storage duration.
- What happens if the library is unloaded before all threads exit?
glibc:
Do not unload the shared object during dlclose().
Consequently, the object's static and global variables are not reinitialized if the object is reloaded with dlopen() at a later time.
DF_1_NODELETE (elf.h)
- Set flag on the DSO until all thread_local objects defined in the DSO are destroyed
- After the flag being cleared, a subsequent dlclose() unloads the DSO
- i.e. dlclose() in the middle of destructing thread_local objects is a no-op
Unloading summary:
- Functions may have lifetime
- Implementations need to prevent objects with thread storage duration from outliving their destructors
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.