On Wed, 2006-03-22 at 18:10 -0800, Sean Hefty wrote: > 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? >
IMO, doing this will result in another IWCM implementation that is about the same complexity... Stevo. _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general