Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Thu, 13 Jun 2002 17:27:55 -0400 (EDT) From: David E Euresti To: Subject: RE: More on passing file descriptors In-Reply-To: <001301c21319$fe0a8e50$0200a8c0@lifelesswks> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, On Fri, 14 Jun 2002, Robert Collins wrote: > > > > -----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 > 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. 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. > > > 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. 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. > > > 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. 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. > > > 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. In it's current incarnation (which I will send in once I get the assignment form squared away) the cygserver gets the call to "hold" handle, duplicates the handle to it's local process, then when it gets the call to "release" it duplicates it into the receiving process, and closes 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. 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. > > > 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. > 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. 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. > Rob > > Thanks for the good discussion, David -- 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/