Hi Ralph, Great to hear back from you.
I am going to try my chance with both options to see which one works better. > does ARE have a launcher that starts its own daemons that fork/exec the user > procs? In essence there is one ARE daemon per node that runs and manages the apps submitted to it. So $are run myapp Will not run myapp directly (i.e. fork/exec), but submits it to the local ARE daemon which subsequently submits it to all remote daemons. The daemon should be started in advance either manually or from a startup script. $are start So, that’s where it gets a bit different than orted, I guess. > You’d also have to implement a PMIx server in those daemons to make it all > work, but you could model that after the one in ORTE. I appreciate it if you tell me where to find the PMIx implementation in ORTE. It should be in ompi/orte subtree, but I can’t tell where. > Otherwise, you’d have to do it the way you describe. You need to replace the > orte/mca/odls/default module with one specifically for ARE so we don’t open > pipes or do anything else ARE wouldn’t like. I will give it a try. One question though. Do you know who is the one who ultimately calls the functions in odls_default_module.c? I.e. if I do a stack trace from within, say odls_default_fork_local_proc(), the names of which important modules would appear in that stack? > Shouldn’t be too hard to do. That makes me feel much better. > I’m happy to provide advice Sure. Very nice of you. I’ll keep you posted. > - fwiw, others have done this before for other systems, and it wasn’t too > horrible. So~ I’m just checking ... by your standards how much horrible is not too horrible? Anyways, Thanks a lot — Kay > On Sep 20, 2015, at 1:32 PM, Ralph Castain <r...@open-mpi.org> wrote: > > Hi Kay > > I suppose you could try to implement the MPI support directly in your plugin > - does ARE have a launcher that starts its own daemons that fork/exec the > user procs? You’d also have to implement a PMIx server in those daemons to > make it all work, but you could model that after the one in ORTE. > > Otherwise, you’d have to do it the way you describe. You need to replace the > orte/mca/odls/default module with one specifically for ARE so we don’t open > pipes or do anything else ARE wouldn’t like. Shouldn’t be too hard to do. > > I’m happy to provide advice - fwiw, others have done this before for other > systems, and it wasn’t too horrible. > > Ralph > > >> On Sep 17, 2015, at 12:16 PM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> >> wrote: >> >> Ralph is the guy who needs to answer this for you -- he's on travel at the >> moment; his response may be a little delayed... >> >> >>> On Sep 16, 2015, at 4:17 AM, Kay Khandan (Hamed) <hkhan...@yahoo.com> wrote: >>> >>> Hello everyone, >>> >>> My name is Kay. I’m a huge "oom-pi" fan, but only recently have been >>> looking at from devel perspective. >>> >>> I appreciate if somebody shows me the entry point into understanding how >>> orterun and user program interact, and more importantly how to change the >>> way they interact. >>> >>> The reason: I am making a plugin for MPI support in another message passing >>> system. This plugin is loaded from a dynamic library sometime after the >>> process is started and is run on a separated tread. Therefore, (1) it does >>> not receive any command line arguments, and (2) it is not allowed to use >>> standard pipes (file descriptors 0,1, 2). With that in mind, I’de like to >>> interface this plugin from inside so-called ARE (which is the name for the >>> runtime environment for this particular message passing system) to our old >>> friend ORTE. I have the option to run “are” as a user program run by >>> orterun. >>> >>> $orterun are ./actual-user-program >>> >>> It might be wishful thinking, but I am also kindda hoping that I could get >>> orterun out of the way all together by embedding a part of its >>> implementation directly inside that plugin. >>> >>> I’de appreciate to hear your insights. >>> >>> Best, >>> — Kay >>> _______________________________________________ >>> devel mailing list >>> de...@open-mpi.org >>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >>> Link to this post: >>> http://www.open-mpi.org/community/lists/devel/2015/09/18038.php >> >> >> -- >> 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 >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2015/09/18070.php > > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2015/09/18079.php
