Here's what I think is a better patch. Or maybe just simpler.
However, I'm still unsure what the effect of this patch on
file descriptor passing might be. Reading the prior code,
and the parallel portions/comments in unix_dgram_recvmsg(),
it looks like there's been a lot of uncertainty as to how
the core infrastructure is doing that
* for all net proto families now (2.5.69+)
+ * Brent Casavant : SOCK_STREAM MSG_PEEK should peek
+ * far e
in unix_stream_recvmsg(),
however once I figure that out a patch should be forthcoming.
Brent
--
Brent Casavant All music is folk music. I ain't
[EMAIL PROTECTED]never heard a horse sing a song.
Silicon Graphics, Inc.-- Louis
noted in the comments in the
provided test program.
Brent
--
Brent Casavant All music is folk music. I ain't
[EMAIL PROTECTED]never heard a horse sing a song.
Silicon Graphics, Inc.-- Louis Armstrong
--
To unsubscribe fr
On Tue, 8 Jan 2008, Tom Spink wrote:
> Ach. I *am* missing something... and what I'm missing is my
> understanding of the sendmsg and recvmsg calls.
No problem. We all have those days. :)
Brent
--
Brent Casavant All music is folk music. I ain't
idea.
Plus it's always good to flush a bug out of hiding, right? ;)
Brent
--
Brent Casavant All music is folk music. I ain't
[EMAIL PROTECTED]never heard a horse sing a song.
Silicon Graphics, Inc.-- Louis Armstrong
--
To
v[i].iov_len = messages[i].length;
The entire "struct sockmsg" is sent across the socket, so the first
size_t in each message contains the length of the entire message
(including the size_t). This size gets picked up at the
recv(...,MSG_PEEK) line in do_consumer().
Thanks,
Brent
--
B
ine
simply confirms that the producer failed as a result of the consumer
closing the socket, not the other way around.
Thanks,
Brent Casavant
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define SOCKNAME "/tmp/pee
