This is the mail archive of the 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: Broken since 1.3.10, or earlier

> -----Original Message-----
> From: Randall R Schulz []
> Sent: Tuesday, July 16, 2002 7:01 PM
> To:;
> Subject: Re: Broken since 1.3.10, or earlier
> Dan,
> 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
> asynchrony.

I thought I smelled something deep down under the hood on this one. Your
guess certainly sounds more scientific than mine would...


Unsubscribe info:
Bug reporting:

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