onReady seems to be a private member, how can i use it

[shuyanzhu]

https://github.com/facebook/CacheLib/blob/195fc7a3f467058326af267809a7ec8589d6f843/website/docs/Cache_Library_User_Guides/HybridCache.md?plain=1#LL66C25-L66C33

[shuyanzhu]

I may figure out why onReady is private. The docment should be updated before onRead is available?

CacheLib/cachelib/allocator/Handle.h

Line 302 in 195fc7a

// TODO: T87126824. The behavior for (2) is far from ideal. CacheLib will

[therealgymmy]

@shuyanzhu: yeah you're right. We have actually changed our thinking since the comment is written. We now think everyone should convert a "not-ready" item-handle to a SemiFuture as that's a pretty standard way of dealing with async now (and also plays well with folly's implementation of coroutine)

we'll update the documentation

[shuyanzhu]

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 use onReady to call my notify callback(cv.notify()) so i can suspend coroutine correctly(cv.wait()).

[therealgymmy]

@shuyanzhu: I suppose you cannot use folly coroutine? You can hack it for now by making onReady() public on your end, and adjust the thread local count yourself for now.

Are you doing this for a production system, or for research?

[shuyanzhu]

I use cachelib in a production system so i cannot use folly coroutine. Yeah, i have made onRead public.

[shuyanzhu]

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.

[shuyanzhu]

@therealgymmy I wonder if 'onReady' will be re-exposed to users.

[therealgymmy]

@shuyanzhu: yeah I filed a ticket for it. We'll think about a better way to expose this. You're right that not everyone will be using folly's version of executors.