On Thu, Jan 12, 2017 at 12:08 PM, Sage Weil <sweil@xxxxxxxxxx> wrote: > On Thu, 12 Jan 2017, Gregory Farnum wrote: >> On Thu, Jan 12, 2017 at 5:54 AM, Jason Dillaman <jdillama@xxxxxxxxxx> wrote: >> > There is option (3) which is to have a new (or modified) >> > "buffer::create_static" take an optional callback to invoke when the >> > buffer::raw object is destructed. The raw pointer would be destructed >> > when the last buffer::ptr / buffer::list containing it is destructed, >> > so you know it's no longer being referenced. >> > >> > You could then have the new C API methods that wrap the C buffer in a >> > bufferlist and set a new flag in the librados::AioCompletion to delay >> > its completion until after it's both completed and the memory is >> > released. When the buffer is freed, the callback would unblock the >> > librados::AioCompltion completion callback. >> >> I much prefer an approach like this: it's zero-copy; it's not a lot of >> user overhead; but it requires them to explicitly pass memory off to >> Ceph and keep it immutable until Ceph is done (at which point they are >> told so explicitly). > > Yeah, this is simpler. I still feel like we should provide a way to > revoke buffers, though, because otherwise it's possible for calls to block > semi-indefinitey if, say, an old MOSDOp is quueed for another OSD and that > OSD is not reading data off the socket but has not failed (e.g., due to > it's rx throttling). > We need to provide some way to cancel requests (at least from the client's aspect), that would guarantee that buffers are not going to be used (and no completion callback is going to be called). Yehuda -- 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
