> Not a lot of people are familiar with fd passing so I'll give
> a short description:
>
> By using AF_UNIX sockets between processes, a process can use
> sendmsg() to send a filedescriptor through the socket where the
> other process will do a recvmsg() to pickup the descriptor.
>
> The "problem" is that if a descriptor is in transit/inflight
> and the sending process closes the file, it still needs to
> remain open for the recipient.
>
> What can happen is:
>
> process A: sendmsg(descriptor)
> process A: exit
> process B: exit
>
> without the garbage collection we'd have leaked a file descriptor
> inside the kernel.
[.....]
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....
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) ?
> --
> -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
> "I have the heart of a child; I keep it in a jar on my desk."
--
Brian <[EMAIL PROTECTED]> <brian@[uk.]FreeBSD.org>
<http://www.Awfulhak.org> <brian@[uk.]OpenBSD.org>
Don't _EVER_ lose your sense of humour !
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
