You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The C binding also exposes a small asynchronous API surface, mirroring Rust's `async` operator. Each async call returns a future handle that you can await or cancel.
131
+
OpenDAL’s C binding mirrors the Rust async operator, but keeps all runtime management on the Rust side so C callers never need to embed Tokio. The design is intentionally future/await centric:
132
132
133
-
- Create an async operator with `opendal_async_operator_new` (cast the returned `op` field to `opendal_async_operator`).
134
-
- Start operations with `opendal_async_operator_stat`, `opendal_async_operator_write`, `opendal_async_operator_read`, and `opendal_async_operator_delete`.
135
-
- Await results using the matching `opendal_future_*_await` helpers, or abort early with `opendal_future_*_free`.
136
-
- For non-blocking event-loop style, poll with `opendal_future_*_poll` which returns `opendal_future_status` (`PENDING`, `READY`, `ERROR`, `CANCELED`) without blocking the thread; call `*_await` once `READY` to consume the result, or keep polling.
133
+
-`opendal_async_operator_new` builds an async operator that internally holds a clone of the core `Operator` plus a handle to OpenDAL’s shared Tokio runtime.
134
+
- Each async method (`*_stat`, `*_write`, `*_read`, `*_delete`) immediately returns an opaque `opendal_future_*` handle. Creating the future is non-blocking—the runtime schedules the real work on its thread pool.
135
+
- You stay in control of when to pull the result. Call `opendal_future_*_await` to block the current thread until the operation finishes, or `opendal_future_*_poll` to integrate with your own event loop without blocking.
136
+
- If you abandon an operation, call `opendal_future_*_free` to cancel it. This aborts the underlying task and drops any pending output safely.
137
+
138
+
Because futures carry ownership of the eventual metadata/error objects, the `*_await` helpers always transfer heap allocations using the same conventions as the blocking API (free metadata with `opendal_metadata_free`, free errors with `opendal_error_free`, etc.).
139
+
140
+
### Usage example
141
+
142
+
Below is a full async stat sequence that starts the request, performs other work, then awaits the result. The same pattern applies to read/write/delete by swapping the function names.
137
143
138
144
```c
139
-
opendal_result_operator_new res = opendal_async_operator_new("memory", NULL);
140
-
const opendal_async_operator* op = (const opendal_async_operator*)res.op;
145
+
#include"opendal.h"
146
+
#include<stdio.h>
147
+
#include<unistd.h>
148
+
149
+
staticvoidsleep_ms(unsigned int ms) { usleep(ms * 1000); }
See `tests/async_stat_test.cpp` for more complete usage with GoogleTest.
186
+
Need non-blocking integration with your own loop? Call `opendal_future_stat_poll(fut.future, &out)` inside your loop. It returns `OPENDAL_FUTURE_PENDING` until the result is ready; once it reports `OPENDAL_FUTURE_READY`, call `opendal_future_stat_await` exactly once to consume the output.
187
+
188
+
See `examples/async_stat.c` for a narrated walkthrough and `tests/async_stat_test.cpp` for GoogleTest-based assertions that cover both success and error paths.
0 commit comments