Expand description
The close entries.
Entry 4 of the audited catalogue, and the one whose membership surprises people.
§Why closing is a catalogue entry at all
CloseHandle looks like bookkeeping, but it is a blocking namespace call.
It waits for outstanding I/O on the handle to complete, and on a dead
network path or an ejected removable device it can block hard – which is
the whole reason this facility exists. A consumer that carefully moved its
opens onto a worker and then closed on its own thread would have moved the
wrong half.
§A handle carries its close routine
The audit found that a close entry cannot assume its routine:
FindCloseChangeNotification closes an
crate::watch::ChangeNotification and CloseHandle is wrong for it,
silently. So the routine travels with the handle rather than being chosen at
the call site, which is the same shape
windows-threadpool-sys already
needed for wait targets.
§A request is consumed by performing it
CloseRequest::perform takes self, so a handle cannot be closed twice
through this type. An unperformed request still closes its handle when
dropped, because the alternative is a leak: a request that quietly did
nothing would be worse than one that closes late.
Structs§
- Close
Request - An owned, marshalable request to close one handle.
Type Aliases§
- CloseFn
- A Win32 routine that closes a handle.