Expand description
Cleanup groups: releasing many thread-pool objects in one step.
A cleanup group tears down every object created into it with a single
CloseThreadpoolCleanupGroupMembers, which waits for executing callbacks and
(optionally) cancels those that have not started. That is the SDK’s answer to
shutting down a subsystem without tracking each object individually.
§Why members are created by the group
Releasing members is bulk and irreversible: afterwards a member must not be used or closed again, and only then is its heap callback context safe to free. An individually-owned object cannot know when that has happened, so the group owns both the members and their contexts.
That ownership is expressed in the types. Members borrow the group, and
CleanupGroup::close_members takes &mut self, so the borrow checker
rejects any use of a member after the group has released it:
let mut group = CleanupGroup::new().expect("create group");
let work = group.create_work(|| {}, None).expect("create work");
group.close_members(false);
work.submit(); // error: `group` is mutably borrowed above§Thread-pool I/O is deliberately excluded
There is no create_io. A TP_IO object must not be closed while any
overlapped operation is outstanding, because the kernel still owns that
operation’s storage – and a cleanup group’s bulk release has no way to
satisfy that precondition for its members. crate::io::ThreadpoolIo
therefore stays individually owned, where its Drop can cancel, drain, and
only then close. Grouping it would trade a guarantee for a convenience.
Structs§
- Cleanup
Group - An owned thread-pool cleanup group.
- Periodic
Timer Member - A periodic timer owned by a
CleanupGroup. - Timer
Member - A one-shot timer owned by a
CleanupGroup. - Wait
Member - A wait object owned by a
CleanupGroup. - Work
Member - A work object owned by a
CleanupGroup.