> Actually, I was thinking about returning an error from the REP/REQ >handler, this I believe is suppose to destroy the communication identifier, >which I presume will generate a REJ? This is at least the behaviour I would >like to see. In this case, since the communication identifier is destroyed >there wouldn't be any other state transitions.
Some thoughts about destroying cm_id's based on a callback return value. Given the current code structure, it's possible for a user to receive multiple simultaneous callbacks. For example, a user could be notified of a reply and reject (sent as a result of an rtu timeout) at the same time. The CM will handle the state transitions properly to fail calls into the API. But I can see where it would be easy for a user to end up trying to destroy the cm_id multiple times, or receiving the second callback after they had already destroyed their context. I'm not seeing an easy way to handle this condition. I think that I need to serialize all callbacks for a given cm_id. - Sean _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
