On Jul 30, 2008, at 11:12 AM, Mark Borgerding wrote:
> I appreciate the suggestion about running a daemon on each of the
> remote nodes, but wouldn't I kind of be reinventing the wheel there?
> Process management is one of the things I'd like to be able to count
> on ORTE for.
Keep in mind that the daemons here are not for process management --
they're for name service.
> Would the following work to give the parent process an intercomm
> with each child?
>
> parent i.e. my non-mpirun-started process calls MPI_Init then
> MPI_Open_port
> parent spawns mpirun command via system/exec to create the remote
> children . The name from MPI_Open_port is placed in the environment.
> parent calls MPI_Comm_accept (once for each child?)
> all children call MPI_connect to the name
It may be problematic to call system/exec in some environments (e.g.,
if using OpenFabrics networks). Bad Things can happen.
> I think this would give one intercommunicator back to the parent for
> each remote process (not ideal, but I can worry about broadcast data
> later)
> The remote processes can communicate to each other through
> MPI_COMM_WORLD.
>
>
> Actually when I think through the details, much of this is pretty
> similar to the daemon MPI_Publish_name+MPI_Lookup_name approach.
> The main difference being which processes come first.
Instead of having the framework call MPI_Init in your plugin, can you
plugin system/exec "mpirun -np 1 my_parent_app"? And perhaps use a
pipe (or socket or some other IPC) to communicate between the
framework process and my_parent_app? I realize it's a kludgey
workaround, but it looks like we clearly have a bug in the 1.2 series
with singletons in this area...
--
Jeff Squyres
Cisco Systems
|
![[Flag]](../../../../../community/mirrors/flag-us.gif){kind=small}