-
Notifications
You must be signed in to change notification settings - Fork 932
RFC: Repository update #516
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
Conversation
|
Part of the reason for the component repository update is in preparation for using the framework structure to validate components. |
|
@bosilca, @jsquyres, @rhc54, and @hppritcha: please comment. The opal destructor function could be used to clean up the tsd and fix the java problem that is currently being tracked in the mailing list. |
|
|
Refer to this link for build results (access rights to CI server needed): |
|
I agree that this approach could be used for resolving the use of destructors in the code's use of pthread_key_create. I'll try out using this branch. |
|
I prefer to have the list of components outside the framework itself, but I can live with the current approach. Other than this minor issue, everything looks OK (mostly as a code removal) |
opal/Makefile.am
Outdated
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.
I think you should treat this separately from whether the compiler supports attribute destructor.
I.e. you should be testing whether the linker supports the -fini option in configure. And it should only be added to LDFLAGS here if the compiler does not support attribute destructor and the linker supports -fini.
If the compiler does not support attribute destructor and the linker does not support -fini, then we'll just have to leak memory / refuse to re-init / opal_show_help("your system sucks; we can't re-init") / whatever.
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.
Ah, yes. Good point. There may be compiler/linker combinations that will not support this. I have no problem leaking memory on those systems. It is only the constructor/destructor tables.
d65e8ca to
a916fac
Compare
|
|
Refer to this link for build results (access rights to CI server needed): Build Log Test FAILed. |
This commit is a rework of the component repository. The changes included in this commit are: - Remove the component dependency code based off .ompi_info files. This code is legacy code dating back 10 years that and is no longer used. - Move the plugin scanning code to the component repository. New calls have been added to add new scanning paths, query available components, and dlopen/load components. - Pass the framework down to mca_base_component_find/filter. Eventually the framework structure will be used to further validate components before they are used. - Add support to the MCA framework system to disable scanning for dlopened components on open (support already existed in register). This is really only relevant to installdirs as it has no register function and no DSO components. Signed-off-by: Nathan Hjelm <hjelmn@lanl.gov>
a916fac to
c954f45
Compare
|
|
Refer to this link for build results (access rights to CI server needed): |
|
@hppritcha I moved the destructor function into PR #528. |
…rtran-libs fortran: link the opal-pal.la library directly
STG 214162 - naive fix for non-blocking io calls
There are two commits in this RFC and I am willing to break it down into two pull requests if requested.
The first commit is a rewrite of the component find/repository code. The rewrite removes the unused component dependency code and changes the way the component repository is handled.
The second commit is based off an RFC from last year. I originally proposed adding a destructor function to handle tearing down the opal class system. This unfortunately could not be supported by PGI. I have updated the idea to use -Wl,-fini to designate the destructor when the compiler has no support. This has been tested with all the major compilers.