I agree - let's not get overly complex unless we can clearly articulate a requirement to do so.
On Thu, Jun 9, 2011 at 10:45 AM, George Bosilca <bosi...@eecs.utk.edu>wrote: > This will require exactly opposite registration and de-registration order, > or no de-registration at all (aka no way to unload a component). Or some > even more complex code to deal with internally. > > If the error manager handle the callbacks it can use the registration > ordering (which will be what the the approach can do), and can enforce that > all callbacks will be called. I would rather prefer this approach. > > george. > > On Jun 9, 2011, at 08:36 , Josh Hursey wrote: > > > I would prefer returning the previous callback instead of relying on > > the errmgr to get the ordering right. Additionally, when I want to > > unregister (or replace) a call back it is easy to do that with a > > single interface, than introducing a new one to remove a particular > > callback. > > Register: > > ompi_errmgr.set_fault_callback(my_callback, prev_callback); > > Deregister: > > ompi_errmgr.set_fault_callback(prev_callback, old_callback); > > or to eliminate all callbacks (if you needed that for somme reason): > > ompi_errmgr.set_fault_callback(NULL, old_callback); > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel >
