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. Thanks Ralph On 12/17/07 6:35 AM, "Jeff Squyres" <jsquy...@cisco.com> 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 <bosi...@eecs.utk.edu> 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 >>>> de...@open-mpi.org >>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >>>> >>> >>> >>> >>> -- >>> Tim Mattox, Ph.D. - http://homepage.mac.com/tmattox/ >>> tmat...@gmail.com || timat...@open-mpi.org >>> I'm a bright... http://www.the-brights.net/ >>> _______________________________________________ >>> 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 >
