delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/2002/07/15/04:31:37

Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Date: Mon, 15 Jul 2002 10:31:27 +0200
From: Corinna Vinschen <vinschen AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: How about this for passing file descriptors?
Message-ID: <20020715103127.A6932@cygbert.vinschen.de>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <Pine DOT LNX DOT 4 DOT 33 DOT 0207131534200 DOT 3194-100000 AT this>
Mime-Version: 1.0
In-Reply-To: <Pine.LNX.4.33.0207131534200.3194-100000@this>
User-Agent: Mutt/1.3.22.1i

On Sat, Jul 13, 2002 at 03:46:37PM -0400, David Euresti wrote:
> Hello,
> 	I'm still thinking about this problem.  Since my first solution
> was shot down because of my use of the cygserver.

You got me wrong.  I appreciate your work and I'm not against inclusion
of your solution.  I just want *another* solution which works w/o the
cygserver.  In many cases a cygserver wouldn't be necessary and I still
like to have a running sshd which doesn't need cygserver.  If cygserver
is running, Cygwin could run your code.

> So here's a way to do it without the cygserver.  
> P1 wants to send FD1 to P2
> 
> #1 P1 calls sendmsg with Data
> 	A.  Extract handle from FD1, H1.
> 	B.  Duplicate H1 -> H1bis
> 	C.  Create an Event E1
> 	D.  Create header as follows:
> 		HANDLE hDescriptor; = H1bis
> 		HANDLEINFO hi;  <--- This is obviously more.
> 		HANDLE HEvent;  = E1
> 		int Process;
> 	E.  Spawn a new thread to wait on event
> 		i.  When event is signalled close H1bis, then exit Thread.
> 	F.  Send header + Data
> 
> #2 P2 calls recvmsg
> 	A.  Get header + Data
> 	B.  Duplicate HEvent into current process -> E2
> 	C.  Duplicate hDescriptor into current process -> H2
> 	D.  Call SetEvent on E2
> 	E.  Turn H2 and HANDLEINFO into FD2
> 	F.  Return data and FD2
> 
> So this will work when the sender wants to close the FD after sending it.  
> Because a duplicate of the Handle is still hanging around in Duplicate 
> Handle.

I began to implement something like that the week before but it's far
from being finshed, mainly because of the problems to duplicate
different types of file handlers.  Each of them needs some different
strategy so I wonder if it makes sense to create a new virtual fhandler
method to do the job.  Anyway, what I'm implementing is the following:

Sender:
- sendmsg() is called, type is AF_LOCAL.
- Count valid descriptors in msg_accrights.
- Create named shmem with header + room for count fhandlers.
- Create named event object
- The shmem gets a unique name.
- Fill shmem with header info (process id) and dup'd fhandlers.
- Create thread.
- Send shmem name over socket to receiver.
- Thread enters 'wait for event' state.

Receiver:
- recvmsg() is called, type is AF_LOCAL
- Read shmem name from socket.
- Open shmem, try OpenProcess(DUP_HANDLE) on sender process.
- If that works, duplicate HANDLEs (no details yet :-)), duplicate
  fhandlers and write '0' into the shmem header as own pid, close shmem.
- Otherwise write own pid into shmem.
- Pulse event object.
- If sucessful, continue recvmsg().
- Otherwise enter 'wait for event' state.

Sender:
- Wake up.
- If shmem header does *not* contain '0' as receiver pid:
  - Try OpenProcess(DUP_HANDLE) on receiver pid.
  - If that works, duplicate HANDLEs and write '0' into shmem header
    as own pid.
  - Otherwise report error.
  - Close shmem.
  - Pulse event object.
- Otherwise close HANDLEs, close shmem.
- Terminate thread.
- Continue.

Receiver:
- Wake up.
- If no error, duplicate fhandlers.
- Close shmem.
- Continue.

What I completely ignored so far is how and when to call your cygserver
code instead of the above.  Are you interested in working on that code,
too?  I'd send you my diffs so far and we definitely need to discuss
this and that.

> It will not work if the sender exits after sending it.  Or rather there 
> will be a race condition.  Is there a way to keep the process alive for a 
> little while?  At least like 10 seconds or until the Event is signalled?

I didn't think of that but I think that's a minor point.  We can
solve that in a later state, isn't it?

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin AT cygwin DOT com
Red Hat, Inc.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019