On Tuesday, June 7, 2011 at 4:55 PM, Josh Hursey wrote:
- orte_errmgr.post_startup() start the persistent RML message. There
does not seem to be a shutdown version of this (to deregister the RML
message at orte_finalize time). Was this intentional, or just missed?
I just missed that one. I've added that into the code now.
- in the orte_errmgr.set_fault_callback: it would be nice if it
returned the previous callback, so you could layer more than one
'thing' on top of ORTE and have them chain in a sigaction-like manner.
Again, you are correct. Rather than just returning the previous callback
(if any) I think it makes more sense to maintain a list of callbacks and
have the errmgr call them directly. That way applications/ompi layers don't
have to worry about calling another callback function.
- orte_process_info.max_procs: this seems to be only used in the
binomial routed, but I was a bit unclear about its purpose. Can you
describe what it does, and how it is used?
I use this to determine how many processes were in the job before we started
having failures. This helps me preserve the structure of the tree as much as
possible rather than completely reorganizing the routing layer every time a
- in orted_comm.c: you process the ORTE_PROCESS_FAILED_NOTIFICATION
message here. Why not push all of that logic into the errmgr
components? It is not a big deal, just curious.
Most of the actual logic that handles the processing of the error messages
is pushed into the errmgr component. The code you see in orted_comm.c is
almost all parsing and resending the list of dead processes to the
appropriate modules. That code will have to be in there no matter what.
I've updated the code and checked it into a bitbucket repository which can
be found here:
Please let me know of any more comments,