Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(bindings/cpp): init the async support of C++ binding #5195

Merged
merged 23 commits into from
Nov 18, 2024

Conversation

PragmaTwice
Copy link
Member

@PragmaTwice PragmaTwice commented Oct 17, 2024

Which issue does this PR close?

Part of #5194.

Rationale for this change

This PR initializes the async version of C++ binding.

What changes are included in this PR?

  • build system support for async C++ API (cmake and build.rs)
  • an initial version of async Operator including write and read methods
  • a test case for async C++ API with cppcoro as a C++ coroutine runtime

Are there any user-facing changes?

Since OPENDAL_ENABLE_ASYNC is off by default, so current users shouldn't feel the difference.

bindings/cpp/CMakeLists.txt Show resolved Hide resolved
bindings/cpp/Cargo.toml Outdated Show resolved Hide resolved
bindings/cpp/build.rs Outdated Show resolved Hide resolved
bindings/cpp/build.rs Outdated Show resolved Hide resolved
bindings/cpp/src/async.rs Outdated Show resolved Hide resolved
@PragmaTwice PragmaTwice marked this pull request as ready for review October 17, 2024 15:30
@PragmaTwice PragmaTwice requested a review from PsiACE as a code owner October 17, 2024 15:30
@PragmaTwice
Copy link
Member Author

PragmaTwice commented Oct 17, 2024

It's ready for review now : )

Comment on lines +46 to +58
auto path = "test_path";
std::vector<uint8_t> data{1, 2, 3, 4, 5};
cppcoro::sync_wait(op->write(path, data));
auto res = cppcoro::sync_wait(op->read(path));
for (size_t i = 0; i < data.size(); ++i) EXPECT_EQ(data[i], res[i]);

path = "test_path2";
cppcoro::sync_wait([&]() -> cppcoro::task<void> {
co_await op->write(path, data);
auto res = co_await op->read(path);
for (size_t i = 0; i < data.size(); ++i) EXPECT_EQ(data[i], res[i]);
co_return;
}());
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A quick demo of async C++ binding.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So cool!

@Xuanwo
Copy link
Member

Xuanwo commented Nov 12, 2024

https://crates.io/crates/cxx-async 0.1.2 has been released, let's move!

@PragmaTwice
Copy link
Member Author

Great. I'll continue on this PR and cxx-async in next few days.

Copy link
Member

@Xuanwo Xuanwo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @PragmaTwice for this PR, really great!

@Xuanwo
Copy link
Member

Xuanwo commented Nov 16, 2024

Inviting @silver-ymz and @xyjixyjixyji to take another look.

Copy link
Member

@silver-ymz silver-ymz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great!

Cmake with a version greater than 3.24 may issue a warning.

CMake Warning (dev) at /usr/share/cmake-3.25/Modules/FetchContent.cmake:1279 (message):
  The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy CMP0135 is
  not set.  The policy's OLD behavior will be used.  When using a URL
  download, the timestamps of extracted files should preferably be that of
  the time of extraction, otherwise code that depends on the extracted
  contents might not be rebuilt if the URL changes.  The OLD behavior
  preserves the timestamps from the archive instead, but this is usually not
  what you want.  Update your project to the NEW behavior or specify the
  DOWNLOAD_EXTRACT_TIMESTAMP option with a value of true to avoid this
  robustness issue.
Call Stack (most recent call first):
  CMakeLists.txt:121 (FetchContent_Declare)

We can fix it in another PR, for example by adding the following to CmakeLists.txt

if (POLICY CMP0135)
    cmake_policy(SET CMP0135 NEW)
endif ()

@Xuanwo
Copy link
Member

Xuanwo commented Nov 18, 2024

Thank you @silver-ymz for the review. Let's move!

Great!

Cmake with a version greater than 3.24 may issue a warning.

CMake Warning (dev) at /usr/share/cmake-3.25/Modules/FetchContent.cmake:1279 (message):
  The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy CMP0135 is
  not set.  The policy's OLD behavior will be used.  When using a URL
  download, the timestamps of extracted files should preferably be that of
  the time of extraction, otherwise code that depends on the extracted
  contents might not be rebuilt if the URL changes.  The OLD behavior
  preserves the timestamps from the archive instead, but this is usually not
  what you want.  Update your project to the NEW behavior or specify the
  DOWNLOAD_EXTRACT_TIMESTAMP option with a value of true to avoid this
  robustness issue.
Call Stack (most recent call first):
  CMakeLists.txt:121 (FetchContent_Declare)

We can fix it in another PR, for example by adding the following to CmakeLists.txt

if (POLICY CMP0135)
    cmake_policy(SET CMP0135 NEW)
endif ()

Thank you for your review! Tracked at #5337

@Xuanwo Xuanwo merged commit d7eb774 into apache:main Nov 18, 2024
30 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants