On Jan 7, 2015, at 11:22 AM, Gilles Gouaillardet <gilles.gouaillar...@gmail.com> wrote:
> Valid options are : > --with-threads e.g. --with-threads=posix e.g. default > And > --with-threads=no > > Except configure will explicitly fail if --with-threads=no is used Which is the moral equivalent of not having this option. :-) (which I think is your point :-) ) > So bottom line, pthreads and pthreads only are usable But my question remains: we all decided that OMPI will *require* pthreads, right? (i.e., configure will fail if pthreads are not available) I am being pedantic here, I know -- but it's slightly different than what you're saying, and this threading stuff is already quite confusing... > Cheers, > > Gilles > > "Jeff Squyres (jsquyres)" <jsquy...@cisco.com>さんのメール: >> On Jan 7, 2015, at 4:25 AM, Gilles Gouaillardet >> <gilles.gouaillar...@iferc.org> wrote: >> >>> Talking about thread support ... >>> >>> i made a RFC several monthes ago in order to remove the >>> --with-threads option from configure >>> >>> /* ompi requires pthreads, no more, no less */ >> >> Did we decide this? (that OMPI *requires* pthreads) >> >> I *think* we did. But I just want to make sure that my (terrible) memory is >> correct... >> >>> it was accepted, but i could not find the time to implement it ... >>> >>> basically, i can see three steps : >>> >>> 1) remove the --with-threads option from configure, check for pthreads, and >>> set the >>> OPAL_HAVE_POSIX_THREADS macro to 1 >> >> Sounds good. >> >>> 2) step 1) + remove #ifdef OPAL_HAVE_POSIX_THREADS and remove dead code >>> (e.g. #ifndef OPAL_HAVE_POSIX_THREADS) >> >> Also make configure fail if pthreads are not available. >> >>> 3) step 1) + step 2) + remove the OPAL thread abstraction layer >>> >>> is it a good idea to implement steps 2) and 3) ? >>> i mean, if there is a chance we might support an other threading model in >>> the future, >>> it might be better to keep some dead code for the time being. >> >> I think the consensus was that pthreads are fine for the foreseeable future. >> If we need to re-add the threading abstraction layer, it's annoying, but >> not difficult. Might as well simplify what we have, since there's no other >> threading system on the horizon that we need to worry about. >> >> -- >> 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 >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2015/01/16750.php > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2015/01/16751.php -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
