This is fairly abstract, so please let me know if my understanding or logic is off anywhere.
Do we really have two conceptual contexts here? One that tracks the user's information and another that interacts with the provider? The user context is created / destroyed by calls to iw_create_cm_id() / iw_destroy_cm_id(). The provider context is "created" before calling connect() or accept(). It's "destroyed" if connect() or accept() fail, CONNECT_REPLY returns a failure, or a CLOSE event occurs. For the events, the context can be considered "destroyed" after the callback that reported these events has returned to the provider. The issue is that we cannot touch either context from the other after it has been destroyed. In turn, this implies that we need to acquire a reference on each context before accessing it. The good news is that acquiring and releasing references is simple and doable. More good news is that destruction of each context will only be initiated once. The bad news is that we cannot block in the thread that reports events, which potentially complicates destruction of the provider context. So, while we are safe having the provider context reference/dereference the user context. The user context may never reference the provider context, because it can be destroyed at anytime after calling connect() or accept(). So, what if we viewed the cm_id as having two pieces, or gave it multiple reference counts, or split it into two structures? Could any of that be used to simplify / validate the design? - 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
