Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 14 Dec 2000 15:47:39 -0800
From:      Alfred Perlstein <bright@wintelcom.net>
To:        Terry Lambert <tlambert@primenet.com>
Cc:        Tony Finch <dot@dotat.at>, Matt Dillon <dillon@earth.backplane.com>, Kirk McKusick <mckusick@mckusick.com>, arch@FreeBSD.ORG, net@FreeBSD.ORG
Subject:   Re: patch to cleanup inflight desciptor handling.
Message-ID:  <20001214154739.A19572@fw.wintelcom.net>
In-Reply-To: <200012142345.QAA16165@usr08.primenet.com>; from tlambert@primenet.com on Thu, Dec 14, 2000 at 11:45:27PM %2B0000
References:  <20001214233914.L92196@hand.dotat.at> <200012142345.QAA16165@usr08.primenet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
* Terry Lambert <tlambert@primenet.com> [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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001214154739.A19572>