Date: Sat, 15 Jul 2006 14:54:05 +0900 From: gnn@freebsd.org To: Robert Watson <rwatson@freebsd.org> Cc: arch@freebsd.org Subject: Re: Proposal: add pru_close protosw method, refactor abort/detach Message-ID: <m2k66ffm6a.wl%gnn@neville-neil.com> In-Reply-To: <20060618014337.V67789@fledge.watson.org> References: <20060618014337.V67789@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At Sun, 18 Jun 2006 02:01:01 +0100 (BST), rwatson wrote: > > > Over the past 6-12 months, I've spent quite a bit of time working with our > socket and protocol locking and reference models. These efforts have been > aimed at a couple of things: Apologies for the length of time I let this sit. > Attached is a patch that attempts to further rationalize tear-down. > Specifically, it refactors pru_detach (disconnect and conditionally > free) and pru_abort (disconnect abruptly and free) into three > protocol switch functions: > > pru_close: socket has been closed and a sensible shutdown without > data loss is desired. > > pru_abort: socket is being aborted, generally due to insufficient queue space > in a listen socket, or close of a listen socket while connections are waiting > to be accepted: close abruptly and potentially with data loss. > > pru_detach: teardown is now unconditional -- both the protocol and socket are > done. > This to me is a sensible approach and if it works for both TCP and SCTP then I suspect it should work for other protocols which are less complicated. > The changes require protocol implementors to distinguish close and > deatch, which while generally clarifying for some protocols (such as > TCP, where the logic becomes much more clear), for others it has > never been clear how exactly close worked, and does not become > clearer. I believe your statements above are clear. Can you put similar, sensible comments in places where protocols implementors are likely to see them? > What I'm looking for: > > - yay/nay on this approach, and the general change in protosw > behavior. It does touch all protocols, but I think makes things > generally more sensible. this doesn't just support the > resock_vertical exploration, but also generally makes things more > sensible by moving towards a more typical constructor/destructor > and avoiding combining protocol state transitions with socket > state freeing. Yay. > - Review of the details of the patch. In particular, help deciding > if my splitting up of events between pru_abort, pru_close, and > pru_detach for each protocol is right. It "looks" OK. Is there a branch you have that I can create a p4 client for and do my usual NetPIPE style abuse testing? I have been trying to make a nightly test script for NetPIPE so it might be a good thing to try on this branch. Later, George
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m2k66ffm6a.wl%gnn>