This is the mail archive of the cygwin@cygwin.com 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: pipe performance problem


Christopher Faylor <cgf-noreply@cygwin.com> wrote:

> If there is no data in a pipe it can wait for 10ms waiting for it, yes.
> See ready_for_read/peek_pipe in select.cc.

Yep i saw the Sleep (10) and though the same thing, but i figured that
can't be it when i commented it out, compiled a new cygwin1.dll and the
10ms delay was still there.

I added some debugging code and narrowed the problem down to five lines.

   26  245082 [main] dd 3100 readv: DEBUG 1.a syscalls.cc
   23  245105 [main] dd 3100 readv: DEBUG 1.b syscalls.cc
   23  245128 [main] dd 3100 readv: DEBUG 2.a syscalls.cc
   23  245151 [main] dd 3100 readv: readv (0, 0x240FD9C, 1) blocking, sigcatchers 4
   24  245175 [main] dd 3100 readv: DEBUG 2.b syscalls.cc
10508  255683 [main] dd 3100 peek_pipe: DEBUG 7.0 select.cc
   76  255759 [main] dd 3100 peek_pipe: /dev/piper, ready for read
   27  255786 [main] dd 3100 peek_pipe: DEBUG 7.1 select.cc
   25  255811 [main] dd 3100 peek_pipe: DEBUG 7.2 select.cc
   26  255837 [main] dd 3100 fhandler_base::ready_for_read: read_ready 1, avail 1
   25  255862 [main] dd 3100 readv: DEBUG 2.d syscalls.cc


If i'm not misinterpreting things readv (DEBUG 2.b) is actually the
problem and not peek_pipe. DEBUG 7.0 is always there, even if there is
no delay, so that cannot be it.


Here is the relevant code in syscalls.cc (line 414):

      debug_printf ("DEBUG 2.b syscalls.cc");
      if (wait && (!cfd->is_slow () || cfd->get_r_no_interrupt ()))
        debug_printf ("no need to call ready_for_read");
      else if (!cfd->ready_for_read (fd, wait))
        {
          debug_printf ("DEBUG 2.c syscalls.cc");
          res = -1;
          goto out;
        }
      debug_printf ("DEBUG 2.d syscalls.cc");


Now i don't really understand what's going on here. But i hope someone
can explain what the problem is or could be.

Just to save you some work, the code in 1.1.18 where the problem didn't
occur looks like this:


  int res;
  if (wait && (!sigcatchers || !fh->is_slow () || fh->get_r_no_interrupt ()))
    debug_printf ("non-interruptible read\n");
  else if (!fh->ready_for_read (fd, wait, 0))
    {
      if (!wait)
        set_sig_errno (EAGAIN); /* Don't really need 'set_sig_errno' here, but... */
      else
        set_sig_errno (EINTR);
      res = -1;
      goto out;
    }

thomas


--
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/


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