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. -- 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
