This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: cygwin fork()
On Fri, Sep 01, 2006 at 10:04:51AM -0700, clayne@anodized.com wrote:
>On Fri, Sep 01, 2006 at 09:34:15AM -0700, clayne@anodized.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.
Opening a file with O_TEXT should not, AFAIK, cause a bunch of one-byte
reads.
A simple test case (tm) seems to confirm that.
cgf
--
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/