Yes, we decided some time back that pthreads is a minimum requirement for Open MPI.
-Nathan On Wed, Jan 07, 2015 at 04:26:01PM +0000, Jeff Squyres (jsquyres) wrote: > 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/ > > _______________________________________________ > 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/16752.php
pgp6ohjPwejs2.pgp
Description: PGP signature
