From owner-freebsd-arch Thu Dec 14 15:52:18 2000 From owner-freebsd-arch@FreeBSD.ORG Thu Dec 14 15:52:13 2000 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 50BBC37B402; Thu, 14 Dec 2000 15:52:13 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eBENldm19603; Thu, 14 Dec 2000 15:47:39 -0800 (PST) Date: Thu, 14 Dec 2000 15:47:39 -0800 From: Alfred Perlstein To: Terry Lambert Cc: Tony Finch , Matt Dillon , Kirk McKusick , arch@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: patch to cleanup inflight desciptor handling. Message-ID: <20001214154739.A19572@fw.wintelcom.net> References: <20001214233914.L92196@hand.dotat.at> <200012142345.QAA16165@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200012142345.QAA16165@usr08.primenet.com>; from tlambert@primenet.com on Thu, Dec 14, 2000 at 11:45:27PM +0000 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Terry Lambert [001214 15:45] wrote: > > >This still leaves the possibility of a circular reference being > > >passed while being passed until the process exits, but I don't > > >think you need to care about that. > > > > That's the whole point of this conversation! > > I don't think you need to care about it. There are valid reasons > for doing the passing, and a core dump of one process in a pair > involved in a pass could leave the thing in limbo. But it is > resolved on process exit. > > I don't think you need to be overly concerned about the thing > being in limbo, since if both processes exit, it's cleaned up. No it's not: Ok, the problem is you have 3 af_unix pairs all open between 2 processes process B sends 3 over 2 to A process B sends 2 over 3 to A process B send 2 and 3 over 1 to A process B closes 1 2 and 3 A then closes 3 2 and then 1 closing 3 and 2 doesn't cause the socketbuffer to be flushed because they are still self referencing. closing 1 causes the socketbuffer to be flushed, on flushing it comes across 2 and drops a reference but doesn't flush, it then hits 3 and drops a reference but doesn't flush. since 3 references 2 and 2 references 3 and nothing else references 2 or 3, we just leaked 2 and 3. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message