On 10 May 2006 12:19, [EMAIL PROTECTED] wrote:
> On Tue, May 09, 2006 at 10:11:35PM -0700, [EMAIL PROTECTED] wrote:
>>
>> So far so good, but if anyone sees anything glaring might as well point it
>> out - although this is not really CW related at this point.
>>
>> -cl
>
> Just to follow up on
On Tue, May 09, 2006 at 10:11:35PM -0700, [EMAIL PROTECTED] wrote:
>
> So far so good, but if anyone sees anything glaring might as well point it
> out - although this is not really CW related at this point.
>
> -cl
Just to follow up on this.. I did take your advice fully Dave, and decided
to ju
On Tue, May 09, 2006 at 03:54:16PM +0100, Dave Korn wrote:
> > You cannot
> > even use the idiom of "well let me just get the rest of this here and I'll
> > make a request for the dropped data after."
>
> Yes you absolutely can. Who said you can't? You're just not trying. It
> works fine.
We
On 09 May 2006 15:36, [EMAIL PROTECTED] wrote:
>> Well, to me this looks like a variation on the classic error made when
>> coding applications which use tcp. Specifically that there is a 1<->1
>> crrespondence between sends( write, writev, etc) on the sending side to
>> rcvs(read, readv, etc) on
On Tue, May 09, 2006 at 07:00:57AM -0700, Mark Pizzolato wrote:
> > 67
> > 68 for (error = 0; !error; ) {
> > 69 error = 1;
> > 70
> > 71 if ((hl = n_recv_iov(s, packet, NE(packet), 60))
> >== (size_t)-1)
> > 72
On 09 May 2006 08:44, [EMAIL PROTECTED] wrote:
> 2. What exactly is the purpose of dummytest() within
> /winsup/cygwin/miscfuncs.cc?
> The actual check_iovec() call with preceeding dummytest():
>
> 162 static char __attribute__ ((noinline))
> 163 dummytest (volatile char *p)
> 164 {
On Tuesday, May 09, 2006 12:44 AM clayne wrote:
[...]
My actual readv() wrapping code is very basic and standard, so I don't
think
it's doing anything evil or causing a problem:
400 size_t n_recv_iov(int s, const struct iovec *v, size_t c, int
tout)
401 {
402 size_t
Warning - LONG and network code related - do not read if not interested
or not versed.
I'm trying to currently debug an issue where readv() seems to be filling
iovec's with bad data or otherwise overflowing when having to deal with a
large receive buffer. I say large receive buffer because I can
8 matches
Mail list logo
