support multiple Runtime::run() calls

[wokron]

PR Type

Enhancement, Tests

---

Description

• Support multiple Runtime::run() calls

• Add thread binding and state reset

• Add tests for multiple runs and cross-thread scheduling

---

Diagram Walkthrough

flowchart LR
  A["Runtime::run()"] --> B["Check run_thread_id_"]
  B -- "First call" --> C["Enable ring & flush queue"]
  B -- "Same thread" --> D["Flush ring & loop"]
  B -- "Different thread" --> E["Throw runtime_error"]
  C --> D
  D --> F["Reset tick_count_ & exit_allowed_"]

Loading

File Walkthrough

	Relevant files
Enhancement	runtime.hpp Refactor runtime state for multiple run calls                        include/condy/runtime.hpp Replaced state machine with atomic bool ring_enabled_ and thread ID tracking Added thread binding check in run() to allow multiple calls from same thread Reset tick_count_ and exit_allowed_ after run() completes Removed State enum and related atomic state variable +33/-44
Tests	test_runtime.cpp Add tests for multiple run scenarios                                          tests/test_runtime.cpp Added test for multiple run() calls from same thread Added test verifying exception on run() from different thread Added test for cross-thread scheduling between runs +51/-0    test_sync_wait.cpp Add sync_wait multiple run test                                                    tests/test_sync_wait.cpp Added test for sync_wait with same runtime multiple times +25/-0

---

[wokron]

/review

[github-actions]

PR Reviewer Guide 🔍

(Review updated until commit 2d9edf5)

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 PR contains tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Missing thread-safety The run() function checks run_thread_id_ without synchronization. If two threads call run() concurrently, both could see run_thread_id_ as default and proceed to enable the ring, leading to undefined behavior. The documentation states this is not allowed, but the code does not enforce it with a mutex or atomic check, making it a potential race condition. if (run_thread_id_ == std::thread::id()) { int r = io_uring_enable_rings(ring_.ring()); if (r < 0) { throw detail::make_system_error("io_uring_enable_rings", -r); } run_thread_id_ = std::this_thread::get_id(); { std::lock_guard<std::mutex> lock(mutex_); flush_global_queue_(); ring_enabled_.store(true, std::memory_order_relaxed); } if (!disable_register_ring_fd_) { io_uring_register_ring_fd(ring_.ring()); } } else if (run_thread_id_ == std::this_thread::get_id()) { flush_ring_(); } else { throw std::runtime_error( "Runtime::run() can only be called from the same thread"); } Possible double enable In the first-run path of run(), io_uring_enable_rings is called without checking if the ring is already enabled. If run() is called multiple times from the same thread, the second call skips the first-run block but does not re-enable the ring. However, if the ring was disabled between runs (not shown in diff), calling io_uring_enable_rings again could fail or cause undefined behavior. The code assumes the ring stays enabled, but the reset logic does not disable it. int r = io_uring_enable_rings(ring_.ring()); if (r < 0) { throw detail::make_system_error("io_uring_enable_rings", -r); }

[github-actions]

PR Description updated to latest commit (fa0860d)

[github-actions]

Persistent review updated to latest commit ca666df

[github-actions]

Persistent review updated to latest commit 2d9edf5