> From: Sean Hefty [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 12, 2005 11:53 AM > > This fell out of the uCM connection ID discussion... > > There's an issue reporting events to userspace clients for an object that a > user > may have destroyed. The problem exists with user verbs, but is much more > likely > to be seen by a userspace CM client. To avoid reporting events for a > destroyed > object, I think that something similar to the following could be used from > userspace:
I had to put something like this in place in the Windows CM, except that I had to use async destroy semantics to allow preserving the existing CM API. > destroy() should set a state marking destruction and wait for a reference > count > to go to 0 before transitioning to the kernel. The kernel code should destroy > the associated kernel object and then discard any unclaimed events. You don't need a state here - just preset the reference count to 1. The sequence should follow something like: 1. Tell kernel to destroy CM ID. 2. Kernel flushes all pending events, completes (with failure) any requests from a previous call to get_event(). 3. deref, and wait for zero. > get_event() should check the object state and discard the event if the object > is > being destroyed. It should increment a reference count before reporting any > events. No need to check for the state. If the object was destroyed already, the user has a bug and there's not much you can do about it. Something like this: 1. inc ref_cnt 2. call kernel to get event. 3. if failure dec ref_cnt. You need to bump the ref_cnt before making the kernel call to get the event to prevent a call to destroy() from blowing the CM ID away while an event request is outstanding (and the status isn't known yet). > put_event() should decrement the reference count and unblock destroy if the > reference count goes to 0. Yep. - Fab _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
