GNU bug report logs - #46494
28.0.50; [native-comp] Problems with async background compile

Previous Next

Full log

View this message in rfc822 format

From: Andrea Corallo <akrl <at> sdf.org>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 46494 <at> debbugs.gnu.org
Subject: bug#46494: 28.0.50; [native-comp] Problems with async background compile
Date: Sun, 14 Feb 2021 08:01:59 +0000

Andy Moreton <andrewjmoreton <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.