On Mon, Apr 16, 2012 at 2:20 PM, Greg Farnum <gregory.farnum@xxxxxxxxxxxxx> wrote: > On Monday, April 16, 2012 at 2:07 PM, Sage Weil wrote: >> On Mon, 16 Apr 2012, Greg Farnum wrote: >> > Or set the bool to true, then do the callback, then signal? >> >> >> That's sort of what I was getting at with >> wait_for_complete_and_callback_returned(). We could make >> wait_for_complete() do that, although it should be a second bool because >> cond.Wait() can wake up nondeterministically (because of a signal or >> something). For example I could clear the callback pointer after it >> returns, and make the wait loop check for the bool and callback_ptr == >> NULL. >> >> It just means the wait_for_complete() does not actually wait for >> is_complete(), but is_complete() && did callback. > > > Okay. I'm just thinking that we need "wait_for_complete()" to be the stronger variant, since that's how it previously behaved. (Whereas I believe that previously is_complete() and is_safe() functioned correctly inside callbacks, correct? So we need to preserve that behavior as well.) > If we want the weaker guarantee for some reason, we can add a wait_for_complete_response() or similar. > wait_for_ack() : got ack or safe response, entails is_ack() wait_for_safe(): got safe response, entails is_safe(), is_ack() wait_for_complete(): done with the request, callback returned, entails is_complete(), is_safe(), is_ack() -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
