This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: More on passing file descriptors


Hello,

On Fri, 14 Jun 2002, Robert Collins wrote:

>
>
> > -----Original Message-----
> > From: cygwin-owner@cygwin.com
> > [mailto:cygwin-owner@cygwin.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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]