> From: Michael S. Tsirkin [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 12, 2005 3:15 PM > > Quoting r. Sean Hefty <[EMAIL PROTECTED]>: > > > > I believe that this is purely a userspace issue. I can't see why > > using a mutex wouldn't work, but I believe that get_event() currently > > blocks waiting for an event. > > > > Note that get_event() may be reporting events associated with an > > object other than the one being destroyed. > > Maybe, create a special kind of event after the object has been destroyed?
Adding such an event in effect makes destruction asynchronous - the user must wait until the destroy event before freeing their context. This is similar to what is done in Windows, but still requires tracking each CM ID in user-mode to provide the proper serialization of events. All non-destroyed events must have been put back to the CM before the destroy event can be generated. Note also that having the kernel take references to track get_event/put_event pairs can lead to issues if an app dies before performing the put unless there's a good way for the kernel to distinguish graceful from abortive CM ID destruction. So I think anyway I look at it, the uCM ends up needing to shadow the CM IDs in user-land to maintain references. If it does that, then Sean's earlier idea of performing reference counting and blocking destruction should work fine and maintain the synchronous behavior that exists today. - 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
