Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 13 Dec 2000 21:47:39 -0800 (PST)
From:      Matt Dillon <dillon@earth.backplane.com>
To:        Brian Somers <brian@Awfulhak.org>
Cc:        Alfred Perlstein <bright@wintelcom.net>, arch@FreeBSD.ORG, net@FreeBSD.ORG, brian@Awfulhak.org
Subject:   Re: patch to cleanup inflight desciptor handling. 
Message-ID:  <200012140547.eBE5lda91759@earth.backplane.com>
References:   <200012132124.eBDLOBU68538@hak.lan.Awfulhak.org>

next in thread | previous in thread | raw e-mail | index | archive | help

:Hmm, the last time i looked at this, I believe the whole thing was 
:dealt with by not increasing the file descriptor reference count 
:when it was put in the message header.  If process A closed the 
:descriptor before process B actually recvmsg()d it, it would be 
:EBADF.  The recvmsg() actually incremented the reference count.
:
:I always assumed that this was a result of not wanting to have any 
:funny garbage collecting code ?
:
:Of course looking at the code now, it increases fp->f_count in 
:unp_internalize(), so maybe I was on drugs then....

     Yes, you were on drugs :-)  The moment the descriptor is 
     queued to the socket, the ref count is bumped.  It's really
     a pointer to the underlying file that is queued (and whos
     ref count is bumped), not the descriptor number.

:Assuming I wasn't on drugs (maybe the behaviour was changed - cvs 
:annotate suggests some activity around March 9, but that was the 
:file*/int alignment stuff), I think it would be valid to go back 
:to the old behaviour (not increasing f_count and letting the original 
:owner actually close the descriptor while f_msgcount != 0).
:
:Does any of this make sense ?  Or am I just describing a different 
:case (where process B doesn't exit) ?

    Well, it sort of makes sense, but only in a very twisted fashion :-).
    sendmsg semantics are that once you queue the descriptor, you can
    indeed close() it without destroying the queued entity.  Think about
    it...  if this were not the case you would be forced to synchronize with
    the receiving process prior to closing the descriptor on your end to
    guarentee its validity on the receiving end, which would be a
    non-trivial piece of userland programming.

    If we did have those semantics then you could in fact throw the 
    in-flight message away when the sending process went away, but you
    would have to implement a secondary ref count to prevent the system
    from throwing away the underlying file until you could clear the
    message(s).  

    We have *NEVER* had those semantics nor would we ever want those 
    semantics.  Even if it were legal (which it isn't), it makes the
    user-level programming too complex and too fragile.

						-Matt



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?200012140547.eBE5lda91759>