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. > > > > 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/
