windows-overlapped-io-sys 1.0.0

Owned overlapped I/O endpoints and pinned operations for Windows IOCP and thread-pool completion.
Documentation 
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

// Copyright (c) 2026 Mike Grier
//! Owned overlapped I/O endpoints and pinned operations for Windows.
//!
//! This crate provides the ownership, association, completion, cancellation, and
//! rundown model for overlapped I/O on top of `windows-sys`. It is the reusable
//! foundation beneath `windows-threadpool-sys`: raw I/O completion ports and the
//! object-based thread pool share endpoint and operation storage while remaining
//! distinct completion backends.
//!
//! # Operation-family adapters
//!
//! Endpoints are created safely with [`UnassociatedEndpoint::open`], and each
//! operation family has an adapter behind an opt-in feature. The `fs` and
//! `socket` adapters are fully safe; the `device` adapter owns its buffers but
//! its `ioctl` is `unsafe`, because an arbitrary control code may embed pointers
//! to buffers the adapter cannot own:
//!
//! - `fs`: file read/write and scatter/gather, on the blocking and IOCP backends.
//!   Fully safe.
//! - `socket`: socket send/receive, on the blocking and IOCP backends. Fully
//!   safe.
//! - `device`: `DeviceIoControl` on both backends, through a buffer-owning but
//!   `unsafe` raw-control-code seam.
//!
//! The default feature set is empty, keeping the core completion machinery (the
//! raw IOCP and blocking backends, owned endpoints, and pinned operations)
//! minimal. A narrow unsafe submission seam ([`AssociatedEndpoint::submit`] and
//! the [`Operation`] primitives) stays available for families without an adapter.
//! Fully generic, fully safe overlapped submission remains intentionally
//! unsolved; the per-family adapters are the sanctioned safe path.
//!
//! # Operation identity
//!
//! Submitting returns an [`OperationId`] that names that operation for the life
//! of the process, not merely while its storage address stays put. Cancelling
//! validates the identity against the backend's live operations first, so an
//! identity kept past its operation's completion is rejected rather than applied
//! to a later operation that reused the same storage. Holding an identity too
//! long is therefore safe, and cancellation races safely against completion.

#![warn(missing_docs)]

#[cfg(windows)]
mod blocking;

#[cfg(windows)]
mod config;

#[cfg(all(windows, feature = "device"))]
mod device;

#[cfg(windows)]
mod endpoint;

#[cfg(all(windows, feature = "fs"))]
mod fs;

#[cfg(windows)]
mod identity;

#[cfg(windows)]
mod iocp;

#[cfg(windows)]
mod operation;

#[cfg(all(windows, feature = "socket"))]
mod socket;

#[cfg(windows)]
pub use blocking::BlockingEndpoint;

#[cfg(windows)]
pub use config::{SourceTrackingAlreadySet, set_source_tracking, source_tracking_enabled};

#[cfg(all(windows, feature = "device"))]
pub use device::DeviceIoControlIo;

#[cfg(windows)]
pub use endpoint::UnassociatedEndpoint;

#[cfg(all(windows, feature = "fs"))]
pub use fs::{FILE_FLAG_NO_BUFFERING, FileIo, PAGE_SIZE, PageBuffers, ScatterGatherIo};

#[cfg(windows)]
pub use identity::{OperationId, OperationRegistry};

#[cfg(windows)]
pub use iocp::{AssociatedEndpoint, Completion, CompletionPort, Issued, Submitted};

#[cfg(windows)]
pub use operation::{Operation, OperationState, reclaim_overlapped};

#[cfg(all(windows, feature = "socket"))]
pub use socket::{AssociatedSocket, BlockingSocket, SocketIo};