On Fri, Jun 16, 2017 at 3:52 PM, Eli Zaretskii <e...@gnu.org> wrote:

> > From: Orgad Shaneh <org...@gmail.com>
> > Date: Fri, 16 Jun 2017 11:49:33 +0300
> > Cc: bug-make@gnu.org
> >
> >  In general, killing subprocesses is problematic on Windows, because
> >  only child processes can be killed, the grandchildren cannot.
> >  Therefore, rearranging your build commands might make the issue go
> >  away.
> >
> > Then this can explain the problem. g++.exe invokes a child process
> cc1plus.exe. Maybe g++ is killed, but
> > cc1plus still has the file open. Then both g++ and make try to unlink
> the file, but they both fail. I attach a
> > Process Monitor log for this scenario.
>
> I don't see any calls to DeleteFile in this log.  I expected to see at
> least one that failed with ERROR_ACCESS_DENIED.  What am I missing?
>

There is SHARING_VIOLATION for both g++.exe and mingw32-make.exe

>> I'm not sure, but you can see in my bug report that the output is
interleaved without this patch.

> Interleaved output is not a problem, it's expected behavior.  And it
> has nothing to do with buffering, since several different instances of
> make are simultaneously writing to the same device.

By "interleaved" I mean that in the *same line* there is "expected" output
and interferences. This happens even without -j. In the example that I gave
in that bug report, it was caused by ^C, which looked like this:

make: *** Deleting file 'obj/m^ainC.oTerminate batch job (Y/N)? '

Is this expected? With the patch it doesn't happen.

- Orgad
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Reply via email to