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 <bosilca_at_[hidden]>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.
> 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