Can you clarify -- I can parse your text multiple ways. Which are you voting for?
1. show_help + return error code in all cases. 2. if OPAL_ENABLE_DEBUG, show_help + exit(1), else silently return error code. 3. show_help. if OPAL_ENABLE_DEBUG, exit(1), else return error code. On Nov 1, 2011, at 4:50 PM, George Bosilca wrote: > This is a much saner solution. We [mostly] stayed away from calling exit deep > into our libraries, there is no reason to add it now. I'll vote in favor of > show_help + return code. > > george. > > On Nov 1, 2011, at 15:14 , Jeff Squyres wrote: > >> We talked about this on the call today. >> >> A good suggestion was made: call show_help/opal_finalize/exit only when >> OPAL_ENABLE_DEBUG is true. Otherwise, return an error code. >> >> If no one objects to this, I'll commit this tomorrow. >> >> >> >> On Oct 31, 2011, at 4:16 PM, Jeff Squyres wrote: >> >>> WHAT: what to do if registering an MCA param results in an error? >>> >>> WHERE: opal/mca/base/mca_base_param.c >>> >>> WHY: MCA param re-registration issues should be treated as OMPI developer >>> errors >>> >>> WHEN: COB Friday, 4 Nov 2011 >>> >>> ----------------- >>> >>> Short version: >>> >>> Re-registering an MCA param to be a different type (e.g., it was initially >>> registered to be a string, but was later re-registered to be an int) should >>> be treated as an OMPI developer error, and should opal_finalize()/exit(1). >>> >>> More details: >>> >>> A mistaken MCA param re-registration recently caused an orted segv. >>> >>> The MCA param subsystem was fixed to avoid this segv, but silently convert >>> the MCA param to the newly-registered type. Upon reflection and some >>> discussion, this seems to be a bad idea. Instead, we should loudly >>> complain via a show_help message and then exit(1). >>> >>> Specifically: this kind of behavior is clearly an error and should be >>> fixed. Unfortunately, in most cases, we don't actually check the return >>> value from MCA param registration functions, so if we change the MCA param >>> function to simply return a non OPAL_SUCCESS status, it's unlikely that >>> anyone will notice until some code tries to read the param value, likely >>> still resulting in a segv. >>> >>> Does anyone have heartburn if I change the error behavior to >>> opal_finalize()/exit(1)? >>> >>> -- >>> Jeff Squyres >>> jsquy...@cisco.com >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>> >>> >>> _______________________________________________ >>> devel mailing list >>> de...@open-mpi.org >>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> >> >> -- >> Jeff Squyres >> jsquy...@cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
