shuyanzhu
shuyanzhu
User should catch this exception and may call the PullCallback::onException(MQException &), and then delete call back if it was allocated in heap when PullCallback::onException(MQException &) don't "delete this", just like...
I mean all PulCalllbacks which were allocated in heap need to "delete this" in onSuccess or onException because there is no AutoDeletePullCallback to be inherited by user. SendCallback does has...
Maybe I make a pr when I'm free?
Looks like there is no pull API anymore, nice(Doge)
Should I close this issue?
I may figure out why `onReady` is private. The docment should be updated before `onRead` is available?https://github.com/facebook/CacheLib/blob/195fc7a3f467058326af267809a7ec8589d6f843/cachelib/allocator/Handle.h#L302
I use bthread in my code, which is stackful coroutine like folly/fiber. In such cases, i think `onReady` is needed beacause folly::SemiFuture::get() would block the pthread of coroutine. I want...
I use cachelib in a production system so i cannot use folly coroutine. Yeah, i have made onRead public.
BTW, i can also new a excutor to complete folly::SemiFuture which had defered bthread's `cv.notify`, but it seems to introduce unnecessary overhead.
@therealgymmy I wonder if 'onReady' will be re-exposed to users.