This is the mail archive of the
mailing list for the Cygwin project.
RE: Broken since 1.3.10, or earlier
- From: "Dan Higgins" <DanHiggins at austin dot rr dot com>
- To: <cygwin at cygwin dot com>
- Date: Tue, 16 Jul 2002 19:25:25 -0500
- Subject: RE: Broken since 1.3.10, or earlier
- Reply-to: <dan at danamis dot com>
> -----Original Message-----
> From: Randall R Schulz [mailto:firstname.lastname@example.org]
> Sent: Tuesday, July 16, 2002 7:01 PM
> To: email@example.com; firstname.lastname@example.org
> Subject: Re: Broken since 1.3.10, or earlier
> I take it that by "inconsistent" you mean the relative ordering of the
> output of the "grep" processes and of the "echo" commands is not
> the strict
> alternation you'd expect.
> That's what I see, anyway. I even saw two lines of grep output
> that follow
> the shell prompt printed after the command "completes."
For the record, if you run the problematic command multiple times, you'll
see that the number of lines returned is not always the same. This is what I
meant by inconsistent. Also, if I first redir the find to a file, then do
while read l; do ... done < theFile
it seems to work fine.
> It seems there's some asynchrony in the processing of the output and that
> somehow, in effect, there's a race condition.
> I believe we've seen other reports of similar problems.
> Someone who knows about the internal architecture of I/O processing in
> Cygwin might be able to shed some light on this. If, for example, there's
> some kind of queuing of I/O operations in Cygwin1.dll between the
> application code (grep or a shell, in this case) and the Windows I/O
> primitives, then there might be an opportunity for this kind of
I thought I smelled something deep down under the hood on this one. Your
guess certainly sounds more scientific than mine would...
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html