We have an application where we use sendmsg() & recvmsg() to pass fds across processes, and it works generally well.  
However, we recently encounted an error condition where it appears as if the sender closed the handle just before the 
receiver duplicated it.

Searching through source, it appears that sendmsg() uses ConnectServerInfo() to pass the information about its open fd, 
and that recvmsg() receives the information, attaches to the sender's resource and sends a "dup" command to create a 
copy of the handle.  But this doesn't explain how the sender knows that the receiver has finished dup'ing the handles 
before it closes them.

In addition, in core_networking/trunk/sys/kern/uipc_usrreq.c, I find the following comment:

         * Idealy, we should also "dup" the fd to ours here, so even if the
         * sender close the fd after send them out, we still have a proper
         * fd and won't confuse receiver...

but then no code to actually implement the "ideal" case!  And then on the receive side:

         * Do nothing under QNX6. All the io_dup_t is passed
         * back to receiver, and receiver will dup it as they want.
         * Note if we did a "dup" in unp_internalize (to prevent sender
         * close fds), we need to close the duped fds after receiver
         * has completed its dup work.

So, I have two questions:

1. Am I reading this correctly, i.e., that there truly is a race condition where sendmsg() just sends the fd information
 and returns, and recvmsg() dups the file handles it received?  In other other words, that there is nothing stopping the
 sender from closing the file handle that it just sent before the receiver has a chance to duplicate the handle it just 
received?

2. If #1 is true, what can be done, short of creating a bunch of synchronization logic to close the loop externally?  
(which would really seem to be covering a bug in the stack.)

Hopefully, I'm reading the code incorrectly and missing some other mechanism that closes this hole.

Thanks,
lew