X-Spam-Check-By: sourceware.org
Date: Fri, 1 Sep 2006 10:04:51 -0700
From: clayne AT anodized DOT com
To: cygwin AT cygwin DOT com
Subject: Re: cygwin fork()
Message-ID: <20060901170451.GC30633@ns1.anodized.com>
References: <20060901100138 DOT GA7444 AT ns1 DOT anodized DOT com> <Pine DOT GSO DOT 4 DOT 63 DOT 0609011023420 DOT 13719 AT access1 DOT cims DOT nyu DOT edu> <20060901153709 DOT GC7663 AT ns1 DOT anodized DOT com> <20060901155403 DOT GE5926 AT trixie DOT casa DOT cgf DOT cx> <20060901160911 DOT GA30633 AT ns1 DOT anodized DOT com> <20060901163415 DOT GB30633 AT ns1 DOT anodized DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060901163415.GB30633@ns1.anodized.com>
User-Agent: Mutt/1.5.11
X-Assp-Spam-Prob: 0.00000
X-Assp-Whitelisted: Yes
X-Assp-Envelope-From: clayne AT ns1 DOT anodized DOT com
X-Assp-Intended-For: cygwin AT cygwin DOT com
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Fri, Sep 01, 2006 at 09:34:15AM -0700, clayne AT anodized DOT com wrote:
> BTW:
> I started up filemon to watch what was going on from it's standpoint, and it
> shows a huge number of READs on libtool, all SUCCESS, but the offset is always
> 1 higher than previous, with a length of 1. Like it's literally reading the file
> 1 byte at a time, then incrementing the offset - until it has fully been read.
> 
> -cl

So right smack dab in the middle of _evalfile() under bash-3.1:

#if defined (__CYGWIN__) && defined (O_TEXT)
  setmode (fd, O_TEXT);
#endif

Also in read_comsub():

#ifdef __CYGWIN__
  setmode (fd, O_TEXT);         /* we don't want CR/LF, we want Unix-style */
#endif

And most importantly in open_shell_script():

  /* Open the script.  But try to move the file descriptor to a randomly
     large one, in the hopes that any descriptors used by the script will
     not match with ours. */
  fd = move_to_high_fd (fd, 0, -1);

#if defined (__CYGWIN__) && defined (O_TEXT)
  setmode (fd, O_TEXT);
#endif

The high fd part jives with the '255' seen in the readv() strace output as well.

This post from 2000 looks related:

http://ecos.sourceware.org/ml/cygwin/2000-10/msg00213.html

In regards to setting the fd to textmode as a way of stripping CRs. Only problem
is that it's making 213,110 syscalls for a 213k libtool script. That cannot be an
efficient way to remove CRs from input.

Found the old references to that too:

#if 0
#if defined (__CYGWIN__)
      if (c == '\n' && istring_index > 1 && istring[istring_index - 2] == '\r')
        {
          istring_index--;
          istring[istring_index - 1] = '\n';
        }
#endif
#endif

I've since removed the setmode() calls within a bash build and am testing now.

UPDATE:
SOLVED.

Filemon now shows bash reading in 8k chunks. There is now no 3 second delay on
reading the rest of the bash script (which I evidenced earlier as well).


p.s. Seriously old stuff in there, for example:

#if defined (__CYGWIN__)
      /* Under CygWin 1.1.0, the unlink will fail if the file is
         open. This hack will allow the previous action of silently
         ignoring the error, but will still leave the file there. This
         needs some kind of magic. */
      if (r == EACCES)
        return (fd2);
#endif /* __CYGWIN__ */


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