bug#12972: [PATCH] Avoid regression in mailcap-view-file similar to Bug#44824

[Eli Zaretskii]

> From: Maxim Nikulin <manikulin@gmail.com>
> Date: Sun, 4 Jul 2021 20:37:24 +0700
> 
> I admit that I wrongly added ":noquery t", for some reason I believed 
> that it allows to choose whether processes are allowed to exist longer 
> than emacs or it is preferred to kill them with emacs. Actually 
> asynchronous processes are killed always and the option manages the 
> query only. This option should be dropped to restore compatibility with 
> previous variant.
> 
> I have not found a way to detach asynchronous process from emacs. 
> Surprisingly it is possible for synchronous processes but it is 
> impossible to detect failure (thus to allow a user to figure out what 
> has happened)
> 
>      (process-file-shell-command command nil 0 nil)
> 
> So process API in emacs is a kind of a short blanket.
> 
> Accidentally I have created an example of program that is incompatible 
> with 'pipe asynchronous processes in emacs
> 
> #!/bin/sh
> exec 1>&-
> exec 2>&-
> sleep 30
> 
> (let ((command "cpu-stress-test")
>        (process-connection-type nil))
>    (start-process-shell-command command nil command))
> 
> And emacs (at least 26.3) consumes 100% CPU for the specified amount of 
> time. I do not see any reason to do so since the program does not do 
> anything ugly. I have not found a way to explicitly force emacs to close 
> pipes. That is why I consider it as an outstanding bug. Emacs must 
> properly handle closed pipes.
> 
> So `process-file-shell-command' ... 0 is better than current 
> `start-process-shell-command' but it does not allow to add error handling.
> 
> So besides that I still have no guess what problem you suspect, now I 
> know that emacs may become mad in response to purely innocent action of 
> a child process.

Sorry, I'm not sure I understand what this is all about.  Are you
still talking about the patch you proposed?