On May 28, 2009, at 2:55 AM, Nadia Derbey wrote:
Well, it didn't because from what I understood, the MPI program need
to
be changed (register a callback routine for the event, activate the
event, etc), and this is something we wanted to avoid.
Combined with what Terry and Ralph already said, I just wanted to make
sure this point is crystal clear: what we're proposing is that you use
peruse *internally* -- there's no need to change MPI applications.
Now, if we are allowed to
1. define new "internal" PERUSE events,
2. internally set the associated callback routines
Peruse was designed to be extensible, I believe. So adding new events
into its infrastructure may not be too terrible (I didn't work on the
peruse stuff; George/Rainer would have to comment on that). The
bigger issue is adding hooks to call those peruse events in the main
progression engines. Adding them to error paths (or already-slow
paths) might not be too bad. But I'm sure that many of us would
scrutinize such changes closely -- as previously stated, we don't want
to negatively impact performance for those who will not be using this
functionality.
--
Jeff Squyres
Cisco Systems
