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

[Andy Moreton <andrewjmoreton@gmail.com>]

On Sat 20 Feb 2021, Eli Zaretskii wrote:

>> From: Andy Moreton <andrewjmoreton@gmail.com>
>> Date: Sat, 20 Feb 2021 12:09:06 +0000
>> 
>> >   M-: (signal-process PROC-ID 'SIGHUP) RET
>> >
>> > (where PROC-ID is the process ID of the Emacs subprocess running the
>> > native compilation), do you see the same crash, or does the subprocess
>> > exit cleanly?  To see the PROC-ID, you can use the Task manager or the
>> > 'pslist' command from the PsTools suite.
>> 
>> I tried that by adding binding this to a key:
>>   (defun signal-hup (proc)
>>     (interactive "nProcess: ")
>>     (signal-process proc 'SIGHUP))
>> 
>> On a x86_64-w64-mingw32 build, sending SIGHUP to a compilation
>> subprocess results in the emacs abort dialog being shown briefly and
>> then disappearing (without user interaction). That dialog should require
>> pressing a button to dismiss it.
>
> I think if the process dies or exits, the dialog is closed.
>
> So, since you seem to be able to reproduce this with a simpler setup,
> please try these:
>
>   . repeat the experiment using 'SIGINT and 'SIGBREAK instead of
>     'SIGHUP
>   . repeat the experiment with w32-start-process-share-console set to
>     a non-nil value (both with SIGHUP and the other 2 SIG* signals)
>
> I'd be interested to know whether the results are different.

Using 'SIGINT or 'SIGBREAK did not seem affect the subprocess at all.

Using "(w32-start-process-share-console t)" with 'SIGHUP seemed to work
without triggering the abort dialog, and killing emacs with async
processes running also did, not trigger the aborts.

    AndyM