> From: Maxim Nikulin <maniku...@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?
