Quoting r. Sean Hefty <[EMAIL PROTECTED]>: > Subject: RE: userspace event reporting > > >> one way to handle this is to have destruction flush events first, then > >> perform the actual destroy... > > > >Right, what I was trying to say in the other thread was: walk the event > >list and kill events for the id that is destroyed. > > > >Does this make more sense? > > I think this is needed, just not sure if it's sufficient. Suppose get_event() > has retrieved an event for a cm_id and is returning the information to > userspace. The application is unaware that an event is pending and destroys > the > cm_id. The uCM allows the destroy to proceed, since it's not yet aware of the > event. The get_event() begins executing userspace code. > > How does the app or uCM locate the data structure associated with the cm_id? > If > destroy succeeded, the structure could have been destroyed. A solution is to > block the destroy, but I'm not sure what would block it. > > - Sean >
Are we talking about multithreaded app? So this is purely userspace issue - cant userspace just take some mutex in get_event and destroy paths? -- MST _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
