Mail Archives: cygwin/2002/06/15/07:37:57
> -----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/
- Raw text -