Track broker-backed eventfd lifecycle and blocking semantics
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- rust
- Domain
- operating-systems
Research direction
Start by reading PR #965 and the broker-backed eventfd introduction in PR #880, then trace EventCounter's broker ObjectHandle lifecycle and read/write blocking paths. Done means broker references are released when eventfd descriptions close and blocking behavior is explicitly made safe or restricted until broker failure notifications can wake waiters.
Written by the indexing model from the issue text.
Description
Follow-up from the broker message-layer cleanup work in PR #965. These issues appear to predate that PR (broker-backed eventfds were introduced in PR #880), so they should be handled in a focused lifecycle/blocking-semantics follow-up.
Issues to address
-
Broker object lifecycle for broker-backed eventfds
EventCounterstores a brokerObjectHandle, but there is no close/drop path that releases the broker object reference when the eventfd file description is closed.- Broker references are currently released when the whole broker session drops, so repeated eventfd create/close loops can exhaust broker reference limits for the lifetime of a broker connection.
-
Blocking vs nonblocking behavior for broker-backed eventfds
- Broker-backed eventfds are created for nonblocking eventfds, but the file status can later be changed to blocking.
- Blocking
EventCounter::read/writewaits on a localPollee, but broker readiness/error notifications are not wired to wake waiters if the broker/control channel fails while a waiter is parked.
Possible directions
- Add an explicit broker object close lifecycle, likely a generic close-object operation routed through protocol/local/host/core and used by
EventCounter/eventfd teardown. - Define broker-backed eventfd blocking semantics. Until broker readiness/error notifications exist, either keep broker-backed eventfds effectively nonblocking-only or add the notification path needed to make blocking waits safe.
- Dominant language
- Rust
- Stars
- 2.7k
- Forks
- 144
- Avg merge
- 12h 21m
- Merged PRs (30d)
- 146
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/litebox
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
All issues in microsoft/litebox
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
gitbutlerapp/gitbutler#15998 · 1 comment ·
-
bug triage:deciding
Difficulty 1/5 Under an hour Newbie friendliness 88/100
open-telemetry/otel-arrow#4132 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100