feat(wasm32): add Runtime/SessionOpenTask C++ wrappers - #810
Draft
Tobias-Fischer wants to merge 1 commit into
Draft
Tobias-Fischer wants to merge 1 commit into
Tobias-Fischer wants to merge 1 commit into
Conversation
zenoh-c's normal synchronous API (z_open() and friends) relies on block_in_place, which panics on wasm32 without atomics (no real threads). zenoh-c's own eclipse-zenoh/zenoh-c#1338 adds a non-blocking C API for this (zc_runtime_t, zc_open_start/zc_open_poll); this adds the corresponding idiomatic C++ wrappers so rmw_zenoh_cpp and other zenoh.hxx consumers can use it without touching the raw C API. Runtime wraps zc_runtime_t (RAII, move-only). SessionOpenTask wraps a pending zc_open_task_t; poll() returns std::nullopt while the session isn't open yet, otherwise the opened Session -- reusing the existing interop::as_owned_cpp_ref<Session>() reinterpret-cast idiom already used elsewhere in this codebase to wrap a freshly-populated z_owned_session_t, no changes to session.hxx needed. Verified end-to-end with a real C++ program linked with emcc and run under Node.js (NODERAWSOCKETS) against a native zenohd: non-blocking open succeeds in 4 pumps, and the resulting Session works normally (zid queryable, kept alive and pumped across further ticks) as long as it isn't dropped in the very same pump/tick that opened it -- doing that specifically hits a block_in_place panic somewhere in session teardown internals unrelated to this change (zenoh::Session::drop() itself is already wasm32-safe); root cause not yet isolated, but this doesn't affect the realistic usage pattern of a session kept alive for the program's lifetime. Depends on an unmerged upstream chain, not ready to build against real dependency versions yet: eclipse-zenoh/zenoh#2790-2799, tokio-rs/mio#2010, tokio-rs/tokio#8489, eclipse-zenoh/zenoh-c#1338. Generated by Claude Code; not yet human-verified. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
zenoh-c's normal synchronous API (
z_open()and friends) relies onblock_in_place, which panics on wasm32 without atomics (no real threads). eclipse-zenoh/zenoh-c#1338 adds a non-blocking C API for this (zc_runtime_t,zc_open_start/zc_open_poll); this PR adds the corresponding idiomatic C++ wrappers sormw_zenoh_cppand otherzenoh.hxxconsumers can use it without touching the raw C API directly.Runtimewrapszc_runtime_t(RAII, move-only).SessionOpenTaskwraps a pendingzc_open_task_t;poll()returnsstd::nulloptwhile the session isn't open yet, otherwise the openedSession— reusing the existinginterop::as_owned_cpp_ref<Session>()reinterpret-cast idiom already used elsewhere in this codebase to wrap a freshly-populatedz_owned_session_t, so no changes tosession.hxxwere needed.Verified end-to-end with a real C++ program linked with emcc and run under Node.js (
NODERAWSOCKETS) against a nativezenohd: non-blocking open succeeds in 4 pumps, and the resultingSessionworks normally (get_zid(), kept alive and pumped across further ticks) as long as it isn't dropped in the very same pump/tick that opened it — doing that specifically hits ablock_in_placepanic somewhere in session teardown internals unrelated to this change (zenoh::Session::drop()itself is already wasm32-safe). Root cause not yet isolated, but this doesn't affect the realistic usage pattern of a session kept alive for the program's lifetime.Still needed for a full
rmw_zenoh_cppport (tracked separately): the actual RMW-side rewrite, replacingrmw_wait_set_data_t's blockingcondition_variable.wait()with a cooperative-polling loop driven byRuntime::pump_once().🤖 Generated with Claude Code