Path: utzoo!attcan!uunet!virtech!cpcahil
From: cpcahil@virtech.uucp (Conor P. Cahill)
Newsgroups: comp.unix.questions
Subject: Re: How to transfer file descriptors with UNIX domain sockets?
Message-ID: <1990Jul01.130157.3627@virtech.uucp>
Date: 1 Jul 90 13:01:57 GMT
References: <1421@tub.UUCP> <10970@hydra.gatech.EDU>
Reply-To: cpcahil@virtech.UUCP (Conor P. Cahill)
Organization: Virtual Technologies Inc., Sterling VA
Lines: 29

In article <10970@hydra.gatech.EDU> gt0178a@prism.gatech.EDU (BURNS,JIM) writes:
>in article <1421@tub.UUCP>, net@tub.UUCP (Oliver Laumann) says:
>> In article <37317@ucbvax.BERKELEY.EDU> rgm@OCF.Berkeley.EDU (Rob Menke) writes:
>>> possible to transfer file descriptors between processes via UNIX domain
>>> sockets using sendmsg(2) and recvmsg(2).
>> The following two trivial programs demonstrate this functionality.
>> The first of them accepts a connection on a UNIX domain socket, opens
>> /etc/passwd, sends the file descriptor to the peer process, and then exits.
>
>I don't understand the concept here - if the program exits, its files are
>closed, and the file descriptor is no longer valid. I know that child procs
>can refer to parent fds even after the parent exits, but merely sending an
>fd in a message - so what? How does the system know that the message
>contains an fd that must remain valid after the program that opened it
>exits?

The system knows because the person, or persons, that added that capability
to the sockets code ensured that the file descriptor that was passed became
a valid file descriptor in the process that received it.

This is not that hard to do since the kernel has control of both processes 
and thier file descriptor tables.

The same capability exists in SVR3 streams although I'm not sure if it has
equal functionality.
-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170