[OMPI devel] v1.5 .so version numbers
SHORT VERSION: We broke ABI from the 1.4 series to the v1.5 series. I propose changing all the libtool .so version numbers as shown below to enforce that break. Can someone sanity check this? Index: VERSION === --- VERSION (revision 23242) +++ VERSION (working copy) @@ -79,12 +79,12 @@ # Version numbers are described in the Libtool current:revision:age # format. -libmpi_so_version=0:2:0 -libmpi_cxx_so_version=0:0:0 -libmpi_f77_so_version=0:0:0 -libmpi_f90_so_version=0:0:0 -libopen_rte_so_version=0:0:0 -libopen_pal_so_version=0:0:0 +libmpi_so_version=1:0:0 +libmpi_cxx_so_version=1:0:0 +libmpi_f77_so_version=1:0:0 +libmpi_f90_so_version=1:0:0 +libopen_rte_so_version=1:0:0 +libopen_pal_so_version=1:0:0 # "Common" components install standalone libraries that are run-time # linked by one or more components. So they need to be versioned as @@ -92,5 +92,5 @@ # components-don't-affect-the-build-system abstraction. -libmca_common_sm_so_version=1:0:0 -libmca_common_mx_so_version=0:0:0 -libmca_common_portals_so_version=0:0:0 +libmca_common_sm_so_version=2:0:0 +libmca_common_mx_so_version=1:0:0 +libmca_common_portals_so_version=1:0:0 MORE DETAILS: libopen_rte.so now wholly includes libopen_pal.so, and libmpi.so wholly includes libopen_rte.so (and therefore also libopen_pa.so). This was done for complex reasons -- the quick explanation is that is sucks because it makes us break ABI right now, but it puts us in a better position for ABI compatibility in the future. I wish that we had figured this out back at v1.3.2 when we introduced ABI compatibility, but we didn't -- so here we are. Cope. To enforce this ABI break, I propose setting the libtool version numbers of all of our shared libraries to 1:0:0. This means that apps linked against v1.5 libmpi.so will *NOT* be able to use libmpi.so from the v1.3 or v1.4 series. They will have to relink (at a minimum). Resetting *all* the library numbers to 1:0:0 is probably overkill (e.g., there's probably little gained by resetting the common libraries to 1:0:0), but it seems like an "ok" thing to do -- reset all the numbers across the board for minimum confusion. Can someone sanity check my rationale here? I'm not tied to this scheme; it just seems simple and, while probably being a bit overly broad, makes the change easy to describe and consistent. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
[OMPI devel] 1.5rc1 has been released
Please beat it in MTT up so that we can get it into shape for final release (we still need to update NEWS to indicate what has really changed): http://www.open-mpi.org/software/ompi/v1.5/ -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] RFC: System V Shared Memory for Open MPI
On Jun 2, 2010, at 11:58 AM, Samuel K. Gutierrez wrote: Good point - I forgot about that. -- Samuel K. Gutierrez Los Alamos National Laboratory On Jun 2, 2010, at 11:40 AM, Jeff Squyres wrote: Don't forget that the RML is also used to broadcast the success/ failure of the creation of the shared memory segment. If the RML goes away, be sure that you can still determine that without hanging. Personally, I still don't see the problem with using the RML stuff... On Jun 2, 2010, at 1:07 PM, Samuel K. Gutierrez wrote: Hi George, That may work - I'll try it. Thanks! -- Samuel K. Gutierrez Los Alamos National Laboratory On Jun 2, 2010, at 10:59 AM, George Bosilca wrote: How about ftok ? The init function takes a file_name as argument, and this file name is unique per instance of the shared memory region we want to create. We can use this file name with ftok to create a unique key_t that can be used by shmget to retrieve the shared memory identifier. george. Hi George, I think ftok brings us back to the atomic file creation problem. In particular, ftok requires pathname be an existing file. As it stands, this file is created by the common sm module. -- Samuel K. Gutierrez Los Alamos National Laboratory On Jun 2, 2010, at 11:53 , Samuel K. Gutierrez wrote: On Jun 2, 2010, at 8:49 AM, Jeff Squyres wrote: On Jun 2, 2010, at 10:44 AM, George Bosilca wrote: Not sure what you mean here. common/sm may create new shmem segments at any time (e.g., during coll sm). The RML message exchange is to ensure that only 1 process creates and initializes the segment and then all the others just attach to it. Absolutely not! The RML messaging is not about initializing the shared memory segment. As stated on my original text it has only one purpose: to ensure the file used by mmap is created atomically. The code for Windows do not exchange any RML messages as the function to allocate the shared memory region provided by the OS is atomic (exactly as the sysv one). I thought that Sam said that it was important that only 1 process shmctl/IPC_RMID...? Hi George, We are using RML messaging in the sysv code to exchange the shared memory ID (generated by exactly one process). I'm not sure how we would go about passing along the shared memory ID without RML, but any ideas are greatly appreciated. Thanks, -- Samuel K. Gutierrez Los Alamos National Laboratory -- 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 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 -- 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 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
[OMPI devel] mpi_comm_spawn
Hello, I want to create a process y from a process x( the master for example). then, i want to communicate between y and another processes in the group of x (between child and his uncles :) ) i have tried to use mpi_comm_connect and mpi_connect_accept, but that concemt requiere taht there is no relationship child/parent The problem is others processes don t know the inter communicator (out of mpi_comm_spawn) I want to communicate child process and all other processes , not only its parent :) thanks in advance
