Date: Thu, 14 Dec 2000 16:11:02 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: Terry Lambert <tlambert@primenet.com> 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. Message-ID: <200012150011.eBF0B2R99195@earth.backplane.com> References: <200012142345.QAA16165@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012150011.eBF0B2R99195>