That would be fine with me - I can grab that out of the trunk and adjust ORTE in my branch instead.
Thanks Ralph On 12/17/07 9:54 AM, "Tim Mattox" <timat...@open-mpi.org> wrote: > How about this as a suggested compromise. > George, could you just do half the patch... where you leave orte alone, > and just move the ompi pointer array implementation down into opal. > That way, any new code can make use of it from opal, and only orte > would need to be adjusted later, after Ralph is done with his changes. > > On Dec 17, 2007 9:18 AM, Ralph H Castain <r...@lanl.gov> wrote: >> 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 >>> >> >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> > >
