From owner-freebsd-net Thu Dec 14 16:11:14 2000 From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 16:11:10 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id C24EC37B402; Thu, 14 Dec 2000 16:11:09 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eBF0B2R99195; Thu, 14 Dec 2000 16:11:02 -0800 (PST) (envelope-from dillon) Date: Thu, 14 Dec 2000 16:11:02 -0800 (PST) From: Matt Dillon Message-Id: <200012150011.eBF0B2R99195@earth.backplane.com> To: Terry Lambert Cc: dot@dotat.at (Tony Finch), tlambert@primenet.com (Terry Lambert), bright@wintelcom.net (Alfred Perlstein), mckusick@mckusick.com (Kirk McKusick), arch@FreeBSD.ORG, net@FreeBSD.ORG, dot@dotat.at (Tony Finch) Subject: Re: patch to cleanup inflight desciptor handling. References: <200012142345.QAA16165@usr08.primenet.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I think there is some confusion over ref counts here. I'm going to try to be clear: You *cannot* use a 1->0 transition on a ref count to cleanup self referential loops in socket message queues from file descriptor passing. Because no 1->0 transition will ever occur, even if both processes exit. This is because the file underlying the descriptor gets its ref count bumped when the *underyling* file is queued over the socket. We are *not* going to remove the ref count bumping. That's silly. We need to track references on the underlying file no matter who is referencing it.. whether it be a process or a message sitting in a socket queue. We are *not* going create a separate ref count field just to track socket queue references, because this breaks the file descriptor passing semantics... it is perfectly legal for the sending process to go away (exit, crash, whatever) after passing a descriptor prior to the receiving process recvmsg()ing the descriptor. The descriptor is not associated with the receiving process's descriptor resources until the receiving process pulls the message... this is necessary, otherwise the receiving process has no ability to control its file descriptors (descriptors would be able to pop up, at any time, outside of the receiving processes control). We are *not* going to allow the descriptors sitting in isolated loops to leak the system to death by ignoring them. There is no simple solution to the garbage collection problem. That's why the current inefficient, slow, spegetti that is the current GC code is still being used. We may be able to make it more efficient, but short of some genius spending a long time figuring out the perfect solution there aren't going to be any rewrites. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message