Define duplicate registration behavior for portable event_add
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 30/100
- Issue 类型
- 功能
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- linux, rust
调研方向
Start by reading std/sys/macos/event.wave:66 and comparing it with the Linux, Windows, and kqueue event-provider sources plus the documented kqueue semantics. Before implementation, discuss the add-versus-modify and token-ownership contract with @LunaStev, as the issue explicitly leaves the design unresolved. Done means each backend has documented same-token and different-token duplicate-add behavior, consistent modify/remove interactions, and native or backend-boundary fixtures covering the complete sequence.
由索引模型根据 Issue 内容生成。
描述
Motivation
Linux epoll ADD and the Windows set reject an already registered descriptor, while kqueue EV_ADD updates an existing ident/filter registration. The portable facade exposes these as the same add operation without defining the duplicate/token replacement contract.
Starting point: std/sys/macos/event.wave:66.
Validation
Audited canonical Wave 540728c2eb6cc12f5c69c3fb3fdb96e07ba059a4 (0.0.1-alpha-dev), whose tree matches the local checkout. Validation: Compared Linux/Windows/kqueue provider source and official kqueue semantics. Executed compiler probes use the matching checkout-built compiler and std on Linux amd64 (Rust 1.89.0 / LLVM 21.1.8). Source/header or mocked checks are not native execution on another OS.
FreeBSD kqueue(2) specifies that re-adding modifies an existing event.
Scope
Choose consistent add-versus-modify and token ownership semantics, or make the capability difference explicit. Do not silently rely on one backend's behavior.
Design discussion required
This issue records a proposal or an unresolved contract; it is not approval to choose new semantics. Please mention @LunaStev to discuss the design before starting implementation.
Completion criteria
- Duplicate add with the same and different tokens has a documented result on each backend.
- Modify/remove interactions follow the same ownership contract.
- Native/backend-boundary fixtures check the complete sequence.
- 主要语言
- Rust
- 星标
- 56
- 派生
- 21
- 平均合并
- 23 小时 20 分钟
- 30 天内合并 PR
- 45
环境准备
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
wavefnd/Wave 的其他 Issue
-
Reject unrepresentable POSIX listener descriptors before Unix-domain accept可能已有人在做 @ShahadatTest 于 7 天前认领。 未关闭bug good first issue
难度 2/5 1-3 小时 新手友好度 84/100
维护者通常 1 天内回复
-
Preserve expression assembly result types when recording HIR conversions可能已有人在做 @hiyouwhatsapp 于 3 天前认领。 未关闭bug help wanted
难度 5/5 一周以上 新手友好度 35/100
维护者通常 1 天内回复
-
bug help wanted
难度 4/5 3-5 天 新手友好度 53/100
维护者通常 1 天内回复
-
Preserve the previous build output when writing its Cargo receipt fails可能已有人在做 @hiyouwhatsapp 于 3 天前认领。 未关闭bug build help wanted
难度 4/5 3-5 天 新手友好度 56/100
维护者通常 1 天内回复
-
Reconcile obsolete staging assets before verifying a new Nightly generation可能已有人在做 @hiyouwhatsapp 于 3 天前认领。 未关闭bug ci help wanted
难度 4/5 3-5 天 新手友好度 48/100
维护者通常 1 天内回复
相似的 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
bug CLI
难度 2/5 1-3 小时 新手友好度 77/100
HigherOrderCO/Bend#2120 ·
-
难度 2/5 1-3 小时 新手友好度 66/100
KNXBench-Labs/KNXBench#47 ·
-
难度 2/5 1-3 小时 新手友好度 88/100
software-mansion/pathfinder#3620 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 88/100
维护者通常 1 天内回复