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


On Wed, 12 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 12:28 AM
> > To: cygwin@cygwin.com
> > Subject: More on passing file descriptors
> >
> >
> > Hello,
> > 	I've talked for a while and sent a couple of messages regarding
> > file descriptor passing through UNIX sockets.  I've done a little more
> > research and determined the following:
> >
> > Refer to http://cygwin.com/ml/cygwin/2002-06/msg00227.html for some
> > details.
> >
> > Unfortunately for this to work properly the message boundaries need to
> > be preserved.  Why? Because if I send two messages with two file
> > descriptors.  And you read all the data in one turn, how are
> > you going to
> > return two file descriptors?
>
> By sending two messages? Seriously, the application buffer != the
> windows socket buffer. 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. Or are you talking about how the
> cygserver manages things? If so:
>
> The cygserver framework manages this transparently. It's a message
> orientated framework so should not have any trouble. What needs to
> happen is the transfer:
> Process 1 FD -> cygserver
> Process 1 FD -> cygserver
> Process 1 -> process 2
> Process 2 FD <- cygserver
> Process 2 FD <- cygserver
>
> (The cygserver might transfer the handles immediately, but the 2nd
> process will still need to query to find out the handle values.
> Alternative, the cygserver could return the handle values to process 1,
> and it then passes the resulting handle values to process 2 which
> _already_ has them in it's process space).
>
> Rob
>
>

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.

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.

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.

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.

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.

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]