Skip to main content

Module cleanup_group

Module cleanup_group 

Source
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§

CleanupGroup
An owned thread-pool cleanup group.
PeriodicTimerMember
A periodic timer owned by a CleanupGroup.
TimerMember
A one-shot timer owned by a CleanupGroup.
WaitMember
A wait object owned by a CleanupGroup.
WorkMember
A work object owned by a CleanupGroup.