Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] pointer_array
From: Ralph H Castain (rhc_at_[hidden])
Date: 2007-12-17 09:18:53

It would require extensive modification as use of the pointer array has
spread over a wide range of the code base. I would really appreciate it if
we didn't do this right now.

The differences are historic in nature - several years ago, the folks
working on the OMPI layer needed to insert some Fortran-specific limits and
type definitions into the opal_pointer_array code. Unfortunately, that
caused type conflicts across a swath of the ORTE code. After a ton of
discussion and debate, there was no way the OMPI folks could guarantee that
they wouldn't need to change those definitions again at some time into the
future - which would again force the ORTE layer to make major changes to
their code.

In addition, the use of an int as the array index in the opal_pointer_array
raised concerns in the ORTE world as we really didn't want to pass generic
variable types between processes. At the time, we weren't sure if the index
in a pointer array was going to need to be passed somewhere in the future -
in fact, the code did pass it at the time in several cases.

So we agreed to simply create separate code that, even though it duplicated
the functionality, ensured that the two could operate semi-independently.

In the intervening time, the OMPI folks seem to have been able to leave the
opal_pointer_array definitions pretty much alone. There have been a few
changes along the way, but nothing overwhelming. In addition, we have found
that the ORTE code no longer needs to pass the array index when sending an
object's data to a remote process - at least, this is true at the moment.

So making the change might be reasonable. If we are going to do that,
though, we need to ensure that all the functionality is replicated (there
are, I believe, a couple of extensions in the orte_pointer_array class), and
we should similarly review the other orte/opal class overlaps.

However, doing all this right now would be a disaster on the tmp branch
where we are revising ORTE. It would be much better to do it after that
branch merges to the trunk, or just make the change in the tmp branch first.
That branch makes much more extensive use of the orte_pointer_array object
than is in the trunk, and it would be a royal pain of conflicts to resolve
it - all for little, if any, gain.


On 12/17/07 6:35 AM, "Jeff Squyres" <jsquyres_at_[hidden]> wrote:

> Adding RHC to the thread...
> I'm guessing that the patch will have to be modified for the ORTE tmp
> branch.
> On Dec 16, 2007, at 6:18 PM, George Bosilca wrote:
>> Right, I wonder why it didn't show in the patch file. Anyway, it
>> completely remove the orte_pointer_array.[ch] as well as the
>> ompi_pointer_array.[ch] file.
>> Thanks,
>> george.
>> On Dec 16, 2007, at 12:01 AM, Tim Mattox wrote:
>>> The patch looks good to my eyeballs, though I've not done any
>>> testing with it.
>>> I presume a follow on patch would remove the orte_pointer_array.
>>> [ch] files?
>>> On Dec 15, 2007 4:01 PM, George Bosilca <bosilca_at_[hidden]> wrote:
>>>> I have a patch that unify the pointer array implementations into
>>>> just
>>>> one. Right now, we have 2 pointer array implementations: one for
>>>> ORTE
>>>> and one for OMPI. The differences are small and mostly insignificant
>>>> (there is no way to add more than 2^31 elements in the pointer array
>>>> anyway). The following patch propose to merge these two pointer
>>>> array
>>>> into one, implemented in OPAL (and called opal_pointer_array).
>>>> If nobody has complained before Wednesday noon I'll commit the
>>>> patch.
>>>> Thanks,
>>>> george.
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel_at_[hidden]
>>> --
>>> Tim Mattox, Ph.D. -
>>> tmattox_at_[hidden] || timattox_at_[hidden]
>>> I'm a bright...
>>> _______________________________________________
>>> devel mailing list
>>> devel_at_[hidden]
>> _______________________________________________
>> devel mailing list
>> devel_at_[hidden]