Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com Date: Thu, 28 Nov 2002 01:20:46 +0100 From: thomas Reply-To: thomas X-Priority: 3 (Normal) Message-ID: <1245871093.20021128012046@huno.net> To: Christopher Faylor Subject: Re: pipe performance problem In-Reply-To: <20021127233624.GK17798@redhat.com> References: <20021122210856.GA10679@redhat.com> <777770015.20021122040845@huno.net> <007301c291ff$eb9ce050$78d96f83@pomello> <21545718.20021122114035@huno.net> <12415481703.20021122220059@huno.net> <20021122210856.GA10679@redhat.com> <5.1.0.14.2.20021122143402.00fdc148@pop3.cris.com> <10824453046.20021123003030@huno.net> <14936170000.20021127223905@huno.net> <20021127233624.GK17798@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Christopher Faylor 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/