Deadlock when Julia is initialized from constructor function.

[tz-lom]

If I use following initializer in Julia compiled library:

void __attribute__((constructor)) init_julia()
{
    jl_options.nthreads = 1;
    static int16_t threads_per_pool[1] = {1};
    jl_options.nthreads_per_pool = threads_per_pool;
    jl_options.nthreadpools = 1;
    jl_options.nmarkthreads = 1;
    jl_options.nsweepthreads = 1;  // this will request a sweep thread
    jl_init_with_image_handle((void *)RTLD_DEFAULT);
}

And then I will load this library in runtime it will cause a deadlock:
Here is what will happen:

1. dlopen is loading my Julia compiled library and set a thread lock
2. During _dl_init phase it will call init_julia function which will call jl_init_with_image_handle
3. Because I request extra thread, ijl_init_ will start extra thread
4. All thread initialization is synchronized in _finish_jl_init_ with wait on a barrier
5. New thread will run jl_concurrent_gc_threadfun which calls to jl_init_threadtls
6. jl_init_threadtls want to call to libunwind unw_ensure_tls function before hitting the wait barrier few lines bellow
   

   julia/src/threading.c

   Line 398 in 812f3be

   jl_dlsym(jl_RTLD_DEFAULT_handle, "unw_ensure_tls", (void**)&jl_unw_ensure_tls, 0, 1);

   
   Because it does dynamic symbol lookup - it calls to dlsym which hits a thread lock from the step 1
7. We are now in deadlock.

Possible solutions:

• Perform unw_ensure_tls after wait barrier (what will happen if thread initialization code would break?)
• Do dynamic linking to unw_ensure_tls instead of runtime linking (libjulia-internal anyway is linked to libunwind already, no need for dynamic name resolution)
• Resolve unw_ensure_tls in ijl_init_ and store it for later use in all threads (so no dynamic name resolution will be performed in separate thread an libdl will not cause deadlock)

[topolarity]

Initializing Julia in an __attribute__((constructor)) is unfortunately problematic for other reasons too.

On Windows for example we run into the following (from https://learn.microsoft.com/en-us/windows/win32/dlls/dllmain):

The entry-point function should perform only simple initialization or termination tasks. It must not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions), because this may create dependency loops in the DLL load order. This can result in a DLL being used before the system has executed its initialization code.

which means that we really cannot use the linker at all or load any libraries from within an __attribute__((constructor)). We need to do both when initializing Julia, so this is unsupported.