-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
Initial support for pthreads + dynamic linking #13245
Conversation
3594754
to
ba8e0d5
Compare
ba8e0d5
to
424ad10
Compare
424ad10
to
39b4e05
Compare
4c5afd5
to
973f7bc
Compare
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.
Impressively small!
973f7bc
to
a571fd1
Compare
This avoids running this code than once in the case that run() is called several times during startup which happens when run dependencies are injected. Split out from #13245
a571fd1
to
07ae0b0
Compare
07ae0b0
to
3e588ab
Compare
This avoids running this code than once in the case that run() is called several times during startup which happens when run dependencies are injected. Split out from #13245
This avoids running this code than once in the case that run() is called several times during startup which happens when run dependencies are injected. Split out from #13245
3e588ab
to
e7aa081
Compare
c0ba508
to
7f21f38
Compare
7f21f38
to
d927be3
Compare
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.
Thanks, makes sense. lgtm.
// Loading of dynamic libraries needs to happen on each thread, so we can't | ||
// use the normal __ATPRERUN__ mechanism. |
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.
// Loading of dynamic libraries needs to happen on each thread, so we can't | |
// use the normal __ATPRERUN__ mechanism. | |
// Loading of dynamic libraries needs to happen on each thread, so we can't | |
// use the normal __ATPRERUN__ mechanism. |
#if MAIN_MODULE | ||
preloadDylibs(); | ||
#else | ||
reportUndefinedSymbols(); |
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.
Not related to this PR, as it's pre-existing, but do you know why the main thread loads dylibs while the side module reports undefined symbols? That seems odd. I'd expect the main module to do both?
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.
Oh, wait, the side module has no JS. So basically, if it's relocatable but not a main module, it only reports undefined symbols, I guess?
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.
Indeed. Although I'm not really sure how much that configuration gets used .. I don't think we test it much.
This support is still experimental and has some major caveats: - Only supports load-time dynamic linking - No support for sharing TLS data between dylibs. The major change is that workers now also call the module `run` function although they exit realy once dynamic libraries have all been loaded. Another change is the dynamic library loading (which needs to run on each new worker) is now seperated from `__ATPRERUN__` (which only wants to run once on the main thread).
d927be3
to
d74bf16
Compare
This support is still experimental and has some major
caveats:
The major change is that workers now also call the module
run
functionalthough they exit early once dynamic libraries have all been loaded.
Another change is the dynamic library loading (which needs to run on
each new worker) is now seperated from
__ATPRERUN__
(which only wantsto run once on the main thread).
See: #3494