bug#46494: 28.0.50; [native-comp] Problems with async background compile

[Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Andy Moreton <andrewjmoreton@gmail.com> writes:

> Problems notes with async compile in native-comp branch on Windows:
>
> a) Bug #46256 describes problems with AOT compiled native-comp emacs not
>    finding prebuilt .eln files when built for mingw64 64bit on Windows.
>
>    As a result, emacs complains with an echo area warning for every .eln
>    file that it cannot find in the expected location.

Please lets discuss each bug in each own thread, there's no need to use
more then one place.

>    The stream of frequent warnings that causes make emacs mostly
>    unresponsive to user input.

You can set `comp-async-report-warnings-errors' to nil if the packages
you use have to many compilation warnings.

For the motivation on reporting these warnings and more please see
bug#44746.

> b) The "background" async compilation of .eln files is CPU intensive and
>    somewhat slow. The default settings run a compile on every available
>    core, which is unfriendly for other workloads running on the same
>    machine.

The default setting ATM should be to run on half of the cores (see
`comp-effective-async-max-jobs'), if that's not the case on Windows
should be fixed.

>    It would be helpful to users to have a command to show the state of
>    the async background compilation, including the running compile
>    processes and the queue of pending compilation requests.

M-x list-processes
M: comp-files-queue

Ideally would be nicer to have a dedicated way to present the async
compilation status, but this does the job (for me at least).

> c) Quitting emacs when async compilation processes are running sometimes
>    causes crashes in the compile processes, which show the emacs abort
>    dialog (once for each async process). The dialogs disappear after a
>    short delay (presumably due to the parent emacs having exited).

Mmmh, I guess this is a Windows specific behavior.  Is there a specific
way to shut-down child processes we would use on Windows not to get
this error?

Thanks

  Andrea