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>