bug#71853: 29.4; `kill-compilation` does not kill compilation process on Windows

[Tze Chian Kam]

> From: Eli Zaretskii
> Date: Tue, 02 Jul 2024 15:41:34 +0300
>
> > From: Tze Chian Kam <tze.chian.kam@gmail.com>
> > Date: Tue, 2 Jul 2024 16:26:32 +1000
> > Cc: 71853@debbugs.gnu.org
> >
> > > From: Eli Zaretskii
> > > Date: Mon, 01 Jul 2024 14:27:09 +0300
> > >
> > > > From: Tze Chian Kam <tze.chian.kam@gmail.com>
> > > > Date: Mon, 1 Jul 2024 12:53:51 +1000
> > > > Cc: 71853@debbugs.gnu.org
> > > >
> > > > > > Sorry, I used a Python file:
> > > > > > ```
> > > > > > import time
> > > > > >
> > > > > > while True:
> > > > > >     print("active")
> > > > > >     sleep(1)
> > > > > > ```
> > > > >
> > > > > And how exactly did you invoke this?  Please show the complete
> > > > > command you typed at the prompt of "M-x compile", because trying
> > > > > to reproduce this (see below) I could't.
> > > >
> > > > I did "M-x compile RET python loop.py RET". Also, when running this
> > > > program, it does not output anything in the *compilation* buffer 
> > > > ("active"
> > > > is not printed every second).
> > >
> > > The fact that it doesn't print "active" is already a sign of some
> > > problem.
> > >
> > > Where did you download your Python from?  Is it a native Windows
> > > executable, or something else, like Cygwin or MSYS2 build of Python?
> >
> > It is a MSYS2 build of Python.
>
> So it's not a native Windows executable, I think, and this could well
> explain what you see.  What does typing the below display?
>
>   M-: (w32-application-type (executable-find "python")) RET

I get "w32-native".

> Also, does setting w32-start-process-share-console to a non-nil value
> help with interrupting the MSYS2 Python?

Yes, it does.

> > I just tested with Emacs in my global path (so I can launch Emacs from
> > Powershell/Command Prompt) and it "C-c C-k' works (using native
> > Windows Python) but I still can't see the prints before killing the process.
>
> Some kind of buffering problem, I guess?  Try invoking "python -u" to
> get unbuffered stdout.

This will work. However, I tested on another C program and the problem
still occurs, meaning that my Emacs is buffering everything for some
reason.

Here is my test file:
```
#include <stdio.h>
#include <unistd.h>

int main() {
  for (int i = 0; i < 5; ++i) {
    printf("%d\n", i);
    sleep(1);
  }
  return 0;
}
```