Folks,
i pushed two commits in order to remove the --with-threads option and
the dead code :
commit 7a55d49ca78bcc157749c04027515f12b026ec33
Author: Gilles Gouaillardet <gilles.gouaillar...@iferc.org>
List-Post: devel@lists.open-mpi.org
Date: Tue Oct 21 19:13:19 2014 +0900
configury: per RFC, remove the --with-threads option
commit 661c35ca677512129cef9bca1bbbf5b5b71d951b
Author: Gilles Gouaillardet <gilles.gouaillar...@iferc.org>
List-Post: devel@lists.open-mpi.org
Date: Tue Oct 21 19:49:58 2014 +0900
cleanup dead code caused by the removal of the --with-threads
configure option
i did not remove the opal abstraction layer (e.g. opal_thread_t and
friends) since it
is not only an abstraction layer, but it brings additional features.
Cheers,
Gilles
On 2015/01/08 1:50, Ralph Castain wrote:
> See note on other thread as to why we made the pthread decision
>
>> On Jan 7, 2015, at 8:30 AM, Jeff Squyres (jsquyres) <jsquy...@cisco.com>
>> wrote:
>>
>> Ok. Then I'm good with Gilles' plan.
>>
>> Anyone else?
>>
>>
>> On Jan 7, 2015, at 11:29 AM, Nathan Hjelm <hje...@lanl.gov> wrote:
>>
>>> 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
>>> _______________________________________________
>>> 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/16753.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/16754.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/16758.php
