Redesign AsyncioWaker around caller-context-independent state transitions
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 25/100
- Loại issue
- Tái cấu trúc
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- rust
- Lĩnh vực
- backend, testing-qa
Hướng nghiên cứu
Start with src/future/asyncio/waker.rs and the runtime attachment check in src/utils.rs, then run the subprocess regressions in python/tests/test_deadlocks.py. Agree on the state-machine design before implementation; done means the listed wake, callback, shutdown, finalization, and subprocess tests define correct behavior without public Python API changes.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Problem and proposed change
AsyncioWaker connects Rust future wakeups to an asyncio.Future. A mutex-protected slot records whether the coroutine is idle, was woken before parking, or is parked on a Python future.
A Rust future can wake:
- synchronously while Python is polling it; or
- later from a detached Tokio worker.
The standard Wake trait does not report which context called it. Current code therefore detects attachment at runtime. Parking also invokes Python event-loop methods while holding the slot mutex. These assumptions make lock ordering, shutdown, and interpreter finalization difficult to reason about.
Redesign the state machine so the mutex protects only short state transitions and ownership moves. Release the mutex before calling Python or destroying Python-owned values. Make wake_by_ref work without detecting caller attachment.
Agree on the design first, then implement it separately.
Context
Current slot states and parking path:
Current explicit wake methods and mixed-context Wake implementation:
Current runtime attachment check:
Existing subprocess regressions:
The same-thread re-entry report #212 was closed as not planned. This proposal is broader structural hardening, not an automatic reopening:
https://github.com/scylladb/python-rs-driver/issues/212
An unconditional Python attachment on every worker wake could hurt performance. Related investigation:
https://github.com/scylladb/python-rs-driver/issues/179
Acceptance criteria
- The slot guard protects only state transitions and ownership moves.
- Python calls and Python-owned-value destruction occur after unlocking.
wake_by_refdoes not need to detect caller attachment.- Wake before, during, and after parking remains correct.
- Tests cover synchronous self-wake and detached worker wake.
- Tests cover callback completion, close, cancel, and exception delivery.
- Task destruction and runtime shutdown behavior are defined.
- Interpreter-finalization behavior is defined if any fallback attaches.
- Potential hangs run in subprocesses with external watchdogs.
- Tests detect lost and duplicate wakeups.
- The worker fast path does not gain unconditional Python attachment without an explicit performance decision.
- No public Python API changes.
- Ngôn ngữ chính
- Rust
- Star
- 6
- Fork
- 8
- Merge trung bình
- 3 ngày 11 giờ
- Pull request đã merge (30 ngày)
- 16
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Có mẫu pull request
- Không có hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của scylladb/python-rs-driver
-
enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 60/100
scylladb/python-rs-driver#224 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
scylladb/python-rs-driver#193 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 18/100
scylladb/python-rs-driver#242 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Migrate to pyo3 0.30Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 22/100
scylladb/python-rs-driver#241 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
scylladb/python-rs-driver#238 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của scylladb/python-rs-driver
Issue tương tự
-
Expose the dot grid colourĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
nannou-org/egui_graph#92 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
documentation good first issue
Độ khó 2/5 Nửa ngày Mức phù hợp với người mới 72/100
sujithputta02/Esapay#13 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
tursodatabase/turso#10002 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
needs triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
topgrade-rs/topgrade#2419 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
review-bot
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
midagedev/bloomery#318 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày