Re: How to design opendal c binding's async api

GitHub user kpole added a comment to the discussion: How to design opendal c binding's async api That's a good question, the existing blocking C API use tokio, but block_on doesn't use tokio's runtime, instand, it operates on the current thread. In contrast, async IO execute at runtime and c

Re: How to design opendal c binding's async api

GitHub user Xuanwo added a comment to the discussion: How to design opendal c binding's async api Here lies the issue: the existing blocking C API already uses tokio under the hood. Could you share some insights into your design for the async C API? GitHub link: https://github.com/apache/ope

Re: How to design opendal c binding's async api

GitHub user kpole added a comment to the discussion: How to design opendal c binding's async api yes, this will cut down the expenses of using the cbinding async framework, at least for what we're doing. GitHub link: https://github.com/apache/opendal/discussions/6082#discussioncomment-140132

Re: How to design opendal c binding's async api

GitHub user Xuanwo added a comment to the discussion: How to design opendal c binding's async api For 1, so you prefer to use tokio directly instead of exposing callbacks and relying on the async runtime from the C side? For 2, yes, having two sets of APIs makes sense to me. GitHub link: ht

Re: How to design opendal c binding's async api

GitHub user kpole added a comment to the discussion: How to design opendal c binding's async api Hi, xuanwo, oceanbase currently uses the blocking version of cbinding and wants to implement async version to reduce the overhead introduced by threading. In response to your question, I have the f

Re: How to design opendal c binding's async api

GitHub user Xuanwo added a comment to the discussion: How to design opendal c binding's async api Some other things to consider: - How should we handle the existing Tokio code? - Should we consider splitting the library into a blocking version and an async version? I can imagine that users

Re: How to design opendal c binding's async api

GitHub user Xuanwo edited a comment on the discussion: How to design opendal c binding's async api Some other things to consider: - How should we handle the existing tokio code? - Should we consider splitting the library into a blocking version and an async version? I can imagine that users

Re: How to design opendal c binding's async api

GitHub user asukaminato0721 added a comment to the discussion: How to design opendal c binding's async api I made a "callback" version in the PR with test and example, feed back welcome. GitHub link: https://github.com/apache/opendal/discussions/6082#discussioncomment-12922194 This is

Re: How to design opendal c binding's async api

GitHub user yuchanns edited a comment on the discussion: How to design opendal c binding's async api Cool. I'm looking forward to it. Go binding can be beneficial from this. GitHub link: https://github.com/apache/opendal/discussions/6082#discussioncomment-12920914 This is an automatical

Re: How to design opendal c binding's async api

GitHub user yuchanns added a comment to the discussion: How to design opendal c binding's async api Cool. I'm looking forward to it. Going binding can be beneficial from this. GitHub link: https://github.com/apache/opendal/discussions/6082#discussioncomment-12920914 This is an automatic

Re: How to design opendal c binding's async api

GitHub user asukaminato0721 added a comment to the discussion: How to design opendal c binding's async api 2 ideas: 1. Callback-based API (very common, but call back hell) 2. Event Loop Integration (integrate into libuv, libevent or other framework) GitHub link: https://github.com/apache/ope

Re: How to design opendal c binding's async api

GitHub user asukaminato0721 edited a discussion: How to design opendal c binding's async api c users have some choices. The main problem is c doesn't have `async/await/yield` keyword. - use callback with libuv, libevent - Manual State Machines - Macro-based "Coroutines" / Protothreads (someth