RE: readv() questions

["Dave Korn" <dave dot korn at artimi dot com>]

On 09 May 2006 08:44, clayne@anodized 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 {
>     165   return *p;
>     166 }
>     167 ssize_t
>     168 check_iovec (const struct iovec *iov, int iovcnt, bool forwrite)
>     169 {

>     176   myfault efault;
>     177   if (efault.faulted (EFAULT))
>     178     return -1;

  This is a hidden try....except construct.

>     190       volatile char *p = ((char *) iov->iov_base) + iov->iov_len -
>     1; 191       if (!iov->iov_len)
>     192         /* nothing to do */;
>     193       else if (!forwrite)
>     194         *p  = dummytest (p);
>     195       else
>     196         dummytest (p);

  This is a buffer size and access mode check.  Since the optimiser would see
that the result of dummytest is not used, if it inlined dummytest it would see
that there are no side-effects either, and discard the memory access
altogether, which would then fail to test for buffer size and availability.
The efault catches the segv if the buffer isn't there or has the wrong access
mode.


> I'm slowly going through the code, which can be a mission, but I'm beginning
> to wonder if this section:

> is culprit... There *are* some relatively spooky looking calls in there,
> coming from a POSIX perspective.

  Couldn't find the standard POSIX definition of "spooky" at 
http://www.opengroup.org/onlinepubs/009695399/xrat/xbd_chap03.html

;)

> But according to my MS API docs on ReadFile - it shall not return until
> it has read the number of bytes requested (or times out, specified
> through SetCommTimeouts I believe - although I do not see it used under
> fhandler_base. 

  No, it wouldn't be, SetCommTimeouts only applies to COM port I/O.

> I presume there is another way through the win32 API when
> using sockets?):

  Sockets are overlapped by default IIRC.

> However this applies to named pipes - not necessarily sockets.  

  The word "necessarily" does not belong in that sentence.  Reading
documentation for X will generally give you little insight into Y.


> Let's just throw out the wild assumption that win32 does something funky
> when data requested via ReadFile() spans an MTU size or resides in a
> following TCP packet associated with the stream - throwing an error and
> saying ERROR_MORE_DATA. 

  I believe it would be within its rights to do so.

> An example case being mine where I request 13
> bytes and we get 2 for instance.  Upon returning from raw_read(), not much
> is done in the way of error checking there either:
> 
> Within fhandler_base::read():
>     725   raw_read (ptr + copied_chars, len);
>     726   if (!copied_chars)
>     727     /* nothing */;
>     728   else if ((ssize_t) len > 0)
>     729     len += copied_chars;
>     730   else
>     731     len = copied_chars;
>     732
>     733   if (rbinary () || len <= 0)
>     734     goto out;
> 
> 
> My actual readv() wrapping code is very basic and standard, so I don't think
> it's doing anything evil or causing a problem:

  There's probably something evil on line 666, but you snipped that!

> Sorry for the ultra mail, but I know for a fact that readv() on cygwin is
> doing bad things when faced with a lot of data to read from the wire. Any
> insights?

  http://cygwin.com/acronyms#PPAST ?

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/