On Wed, 21 Jan 2026 18:37:56 -0800 Bobby Eshleman wrote: > > > Show an example of the three steps: returning the tokens, unbinding, and > > > closing the > > > sockets (TCP/NL)? > > > > TBH I read the doc before reading the code, which I guess may actually > > be better since we don't expect users to read the code first either.. > > > > Now after reading the code I'm not sure the doc explains things > > properly. AFAIU there's no association of token <> socket within the > > same binding. User can close socket A and return the tokens via socket > > B. As written the doc made me think that there will be a leak if socket > > is closed without releasing tokens, or that there may be a race with > > data queued but not read. Neither is true, really? > > That is correct, neither is true. If the two sockets share a binding the > kernel doesn't care which socket received the token or which one > returned it. No token <> socket association. There is no > queued-but-not-read race either. If any tokens are not returned, as long > as all of the binding references are eventually released and all sockets > that used the binding are closed, then all references will be accounted > for and everything cleaned up.
Naming is hard, but I wonder whether the whole feature wouldn't be better referred to as something to do with global token accounting / management? AUTORELEASE makes sense but seems like focusing on one particular side effect.
