Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT cygwin DOT com Delivered-To: mailing list cygwin-developers AT cygwin DOT com Message-ID: <01b701c22bf1$d08e88f0$1800a8c0@LAPTOP> From: "Robert Collins" To: References: <20020715103127 DOT A6932 AT cygbert DOT vinschen DOT de> <006b01c22be7$15deadf0$1800a8c0 AT LAPTOP> <20020715131019 DOT C17700 AT cygbert DOT vinschen DOT de> Subject: Re: How about this for passing file descriptors? Date: Mon, 15 Jul 2002 21:21:50 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 ----- Original Message ----- From: "Corinna Vinschen" To: Sent: Monday, July 15, 2002 9:10 PM > Perhaps that's not even needed. We already have a couple of methods > which are involved when duplicating handles between processes, namely > dup(), fixup_before_fork(), fixup_after_fork(), fixup_after_exec(). Hmm, the difference being that these methods are all synchronous. generic passing of file descriptors is not synchronous. > Basically they are only restricted in their functionality since they > only get the *parent* process handle. If we generalize this stuff > to get a *source* and a *destination* process handle instead, the > whole stuff would be available for situations besides fork/exec... Remember that we don't know the destination process handle for this scenario, all we know is that we need to prepare the fd for *some* process to recieve. Rob