1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
//! I/O backend implementations for lio.
//!
//! This module provides the abstraction layer for different I/O backends and their
//! implementations. It defines the core trait [`IoBackend`] that all backends must
//! implement and manages the lifecycle of I/O operations.
//!
//! # Architecture
//!
//! The backend system is designed for thread-per-core runtime integration:
//!
//! - **[`IoBackend`]**: Unified trait for submission and completion. Each platform has
//! specific implementations (io_uring on Linux, kqueue on macOS/BSD, IOCP on Windows).
//! - **[`OpStore`]**: Thread-local storage for in-flight operations.
//!
//! # Design Goals
//!
//! - **Zero runtime allocation**: All capacity is pre-allocated via [`init`](IoBackend::init)
//! - **Dyn-compatible**: Backends can be used as `Box<dyn IoBackend>`
//! - **Thread-local ownership**: Each thread owns its backend instance (`&mut self`)
//! - **Batched submission**: Push multiple ops, flush once
//!
//! # Example
//!
//! ```
//! use lio::backends::{IoBackend, pollingv2::Poller};
//! use std::time::Duration;
//!
//! // Create and initialize backend
//! let mut backend = Poller::default();
//! backend.init(1024).unwrap(); // Pre-allocate for 1024 concurrent ops
//!
//! // Submit a nop operation
//! backend.push(1, lio::op::Op::Nop).unwrap();
//! backend.flush().unwrap();
//!
//! // Poll for completions (non-blocking)
//! let completions = backend.wait_timeout(Some(Duration::ZERO)).unwrap();
//! ```
pub use *;
pub use *;
use io;
use Duration;
use crateOp;
/// Error types that can occur when submitting operations to the backend.
/// Represents a completed I/O operation.
///
/// This type is returned by backend handlers when an operation completes,
/// containing the operation ID and its result.
/// Unified I/O backend trait for thread-per-core runtimes.
///
/// This trait combines submission and completion handling in a single interface,
/// designed to be owned by a single thread (`&mut self` everywhere). It's
/// dyn-compatible, allowing runtime selection of backends via `Box<dyn IoBackend>`.
///
/// # Lifecycle
///
/// 1. Create backend with `Default::default()` or backend-specific constructor
/// 2. Call [`init`](Self::init) to pre-allocate resources (zero runtime allocation)
/// 3. Use [`push`](Self::push) + [`flush`](Self::flush) to submit operations
/// 4. Use [`wait_timeout`](Self::wait_timeout) to retrieve completions
///
/// # Thread Safety
///
/// Backends are designed for single-thread ownership. They are intentionally
/// not `Send` by default. Runtime authors control threading by creating one
/// backend per thread.