-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor julia initialization to behave better when used as a dylib #56334
base: master
Are you sure you want to change the base?
Conversation
…ing embedding julia as a shared library behave better
2f6a6c4
to
34fe416
Compare
// This code path assumes that you are either an executable or dylib with the sysimage linked in | ||
jl_base_image_handle = sysimg_handle; | ||
julia_init(JL_IMAGE_IN_MEMORY); | ||
jl_enter_threaded_region(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like it's possible for code (on another thread) to start executing before we enter_threaded_region
here
I assume that it's OK for us to enter the region after-the-fact, and that will still allow any IO to eventually be scheduled?
|
||
// Should be called in an attribute constructor function to make initialization threadsafe when embedding as an SO. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does this comment mean? This is an __attribute__((constructor))
julia_init(jl_options.image_file_specified ? JL_IMAGE_CWD : JL_IMAGE_JULIA_HOME); | ||
jl_atomic_store_release(&jl_runtime_is_initialized, 1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be set by julia_init
instead?
It seems like embedding applications might call that directly
XSTR(jl_find_dynamic_library_by_addr), M); | ||
} | ||
auto this_func = builder.GetInsertBlock()->getParent(); | ||
handle = builder.CreateCall(dladdr, {ConstantExpr::getBitCast(this_func, builder.getPtrTy())}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we ever use this in pkgimages?
It seem like it will get the wrong handle in that case.
The big changes are moving initialization to when someone calls into julia, making it all automatic. (It still supports manually initializing the runtime). I'm not done with this because i still need to figure out how to embed runtime arguments. Currently it's piped as a string but it's not clear yet if that's the best way forward.
We maybe want to make the changes to adopt thread handling only exist behind a flag. Though that potentially doesn't add much because essentially this adds a very predictable null check to ccallable