Thanks,
george.On Dec 17, 2007, at 2:22 PM, George Bosilca wrote:
Sound good. I will replace all references to ompi_pointer_array as well as orte_pointer_array in the ompi layer (some BTL use the orte_pointer_array) and replace them with the opal_pointer_array. I'll avoid any modification of the orte layer.I'll commit tomorrow morning. Thanks, george. On Dec 17, 2007, at 12:04 PM, Ralph H Castain wrote:That would be fine with me - I can grab that out of the trunk and adjustORTE 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 ortewould 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 ifwe 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 totheir 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), andwe 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 resolveit - 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 tmpbranch. 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 intojustone. Right now, we have 2 pointer array implementations: one forORTEand one for OMPI. The differences are small and mostly insignificant (there is no way to add more than 2^31 elements in the pointer arrayanyway). 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_______________________________________________ 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
smime.p7s
Description: S/MIME cryptographic signature
