On Mon, 16 Apr 2012, Greg Farnum wrote: > On Monday, April 16, 2012 at 12:37 PM, Yehuda Sadeh Weinraub wrote: > > On Mon, Apr 16, 2012 at 12:00 PM, Sage Weil <[email protected] > > (mailto:[email protected])> wrote: > > > > > > I pushed a wip-2301 that does this. The downside to this approach is that > > > the is_safe() and is_complete() methods will return false until after the > > > callback returns, which includes the callback itself. So a callback that > > > assumes that is_complete() will return true will be wrong. > > > > > > If that's not okay, the alternative is to make the wait_for_complete() > > > actually be a wait_for_complete_and_callback_has_returned(). That drops > > > the symmetry between wait_for_complete() and is_complete(), which is > > > awkward. > > > > > > maybe is_ack(), is_safe() and is_complete()? > > > > Yehuda > > -- > > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > > the body of a message to [email protected] > > (mailto:[email protected]) > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > 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. sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
