This is the mail archive of the 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

> -----Original Message-----
> From: 
> [] On Behalf Of David E Euresti
> Sent: Wednesday, 12 June 2002 12:28 AM
> To:
> 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 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).


Unsubscribe info:
Bug reporting:

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