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: Sat, 15 Jun 2002 21:37:28 +1000
Message-ID: <002301c21461$0794a300$0200a8c0@lifelesswks>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-Reply-To: <Pine.GSO.4.30L.0206131659440.501-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: Friday, 14 June 2002 7:28 AM

> Actually it does, because the sending process doesn't know where the
> handle is going.  What if this socket has been duplicated by a fork
> or something, or if it has been passed around multiple times. 
>  There may
> be multiple exit points for the data, and only one of them 
> picks it up.
> It can't duplicate a handle unless it knows its destination, 
> that's why
> process 2 needs to tell the cygserver what the destination is.

Ah, ok that's cool. Makes sense too :].
 
> Here's an example of how it's used.
> http://www.cs.bilkent.edu.tr/~korpe/slides12.ppt
> You have to go a couple of pages in, but it's the best 
> description I could
> find.

Thanks, I'll read as soon as I have some time.

> > Perhaps the adv prog book covers this.
> 
> What happens in UNIX is that the data gets split up.  You 
> only read one
> message at a time, because it has a file descriptor attached. 
>  So in your
> example P2 would be forced to make 3 reads to finish all the 
> data.  No way
> around it.

So fundamentally, we need a mechanism to perform that split up for
cygwin - which is what you were discussing before. Yes, I'm up with the
play now. 

Does this only apply to domain sockets? If so, then we can go for the
2-read approach IMO.


> it in the local process.  So you could say that all that the cygserver
> buffers is a handle.  All the other description information 
> is passed in a
> tag.

Cool
 
> The cygserver duplicates it locally because the destination 
> of the handle
> is not yet known.  So it has to wait until the receiving 
> process says, I'm
> the receiver give me the handle.  Yes it's insecure but the
> DuplicateHandle call is insecure.
 
Well, DuplicateHandle isn't that insecure, as the first process does
know WHO it's sending the data too. For the FD passing, I suggest
including a token generated by the cygserver in the FD message send over
the socket. The retriever must present the same token to retrieve the
handles.

> Data length tagging would work except that there's no way to take
> advantage of doing multiple writes and one giant recv.  
> Currently I see no
> way of determining if there is another tag coming.

Well, recv shouldn't be too slow as it's all in memory already anyway.
If we use zero-copy it would be even nicer. 
 
> For example if you tag all data, and you send 1 byte packets, but you
> receive 10 byte packets, your tag would say that you have a 1 
> byte packet.
> But you don't know if you have another packet waiting.  And 
> there's no way
> to determine that without doing something bad, like blocking, 
> or setting
> errno.

Can't you wait on the socket with a delay of 0? 

> Thanks for the good discussion,

No probs, I enjoy it.

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/