Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
From: "Robert Collins" <robert DOT collins AT syncretize DOT net>
To: "'David E Euresti'" <davie AT MIT DOT EDU>, <cygwin AT cygwin DOT com>
Subject: RE: More on passing file descriptors
Date: Fri, 14 Jun 2002 06:36:27 +1000
Message-ID: <001301c21319$fe0a8e50$0200a8c0@lifelesswks>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <Pine.GSO.4.30L.0206111106290.20232-100000@magic-pi-ball.mit.edu>
Importance: Normal


> -----Original Message-----
> From: cygwin-owner AT cygwin DOT com 
> [mailto:cygwin-owner AT cygwin DOT com] On Behalf Of David E Euresti
> Sent: Wednesday, 12 June 2002 1:29 AM
 
> Yes the second process will need to query the cygserver for 
> the FD.  And
> actually the cygserver will also want to Duplicate the handle, because
> process 1 will probably close the handle after it sends it.
> Process 2 however can only call the cygserver inside calls to recvmsg.
> so pretend this happens.
> Process 1 - sends a 1 byte packet with an FD.
> Process 1 - sends another 1 byte packet with an FD
> Process 2 - reads a 2 byte message, and gets the FD from the 
> cygserver, it
> never calls recvmsg again because there's no more data.  And 
> we're left
> with one FD floating in the air.

Process 2 should not have to call the cygserver. The cygserver will
duplicate the handles directly to Process 2 (for simplicity and
efficiency), and process 1 will pass enough detail for process 2 to
create the internal structures.

> I suggest reading the semantics of passing file descriptors in Unix in
> "Advanced Programming in the Unix environment".  This is 
> assuming that we
> want this to look like Unix.

Hmm, well I'll add it to my Amazon wishlist. Until then, someone else
will have to make use of fair use rights and quote the relevant section
to me.
 
> Regarding "Cygwin will -need- to have the capability to 
> buffer temporarily
> any data after the end of a received message for the 
> application, so this
> isn't an issue."  If cygwin buffers data then we'll also have 
> to modify
> select, which is not something I want to do.  Which is why we 
> let winsock
> take care of the buffering.  And I don't see how you can 
> determine whether
> there is any more data after the end of a message, without 
> using MSG_PEEK,
> or something hideous like that, because you wouldn't want to 
> block on a
> read if you already got some data.

Urk. Well let me offer a different scenario:

Ignore where the cygserver sits, this is orthogonal

P1 writes some data to a socket connected to P2.
P1 sends FD#1 to P2.
P1 sends FD#2 to P2.
P2 reads the available data, realises that it got more than it expected,
what happens to the two FD messages?

Perhaps the adv prog book covers this.
 
> And regarding the cygserver, if we pass all the fd stuff in a 
> tag, then we
> just really need two functions in the cygserver.
> HOLD - hold this handle for me, give me the value of the 
> handle you are
> holding
> RELEASE - release this handle, because I've duplicated it.

Huh? That's a little low level for my taste. Why not just encapsulate
the whole lot:
SENDFD(target_process,handle1,handle2...handlen)

There's no need for the cygserver to buffer anything at all.
 
> However I would like to know which scheme do you (plural) 
> think is better,
> MSG_OOB, Tagging all data (including, sends, writes, writev), 
> or cygserver
> micromanagement.

cygserver micromanagement isn't needed. I have a horrible suspicion that
data length tagging is needed. On the up side it will correct the
recently reported issue with domain sockets returning fractional data
from single writes as a freebie.

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/