emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Maxim Nikulin <manikulin@gmail.com>
Cc: 12972@debbugs.gnu.org
Subject: bug#12972: [PATCH] Avoid regression in mailcap-view-file similar to Bug#44824
Date: Sun, 04 Jul 2021 16:49:53 +0300	[thread overview]
Message-ID: <83zgv2gpdq.fsf@gnu.org> (raw)
In-Reply-To: <c260c264-c434-4fd2-0e76-8d32256e63bb@gmail.com> (message from Maxim Nikulin on Sun, 4 Jul 2021 20:37:24 +0700)

> 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?

  reply	other threads:[~2021-07-04 13:50 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <F3C1A7E58B2441F7A674239043AC031A@us.oracle.com>
2021-06-01  6:56 ` bug#12972: 24.3.50; Move `org-open-file' and associated code out of Org mode Lars Ingebrigtsen
     [not found] ` <87r1hmdqek.fsf__16088.3597027109$1622530682$gmane$org@gnus.org>
2021-06-02 16:20   ` Maxim Nikulin
2021-07-01 17:01   ` bug#12972: [PATCH] Avoid regression in mailcap-view-file similar to Bug#44824 Maxim Nikulin
2021-07-01 18:38     ` Eli Zaretskii
     [not found]     ` <835yxtlw14.fsf__2546.8955327355$1625164803$gmane$org@gnu.org>
2021-07-02 12:21       ` Maxim Nikulin
2021-07-02 12:37         ` Eli Zaretskii
     [not found]         ` <837di8ki24.fsf__46278.4886871063$1625229533$gmane$org@gnu.org>
2021-07-02 16:24           ` Maxim Nikulin
2021-07-02 17:28             ` Eli Zaretskii
     [not found]             ` <831r8gk4m0.fsf__14172.0669272885$1625246977$gmane$org@gnu.org>
2021-07-03 11:29               ` Maxim Nikulin
2021-07-03 11:56                 ` Eli Zaretskii
     [not found]                 ` <83im1ripaz.fsf__31901.4239286602$1625313464$gmane$org@gnu.org>
2021-07-04 13:37                   ` Maxim Nikulin
2021-07-04 13:49                     ` Eli Zaretskii [this message]
2021-07-05 13:12                       ` Maxim Nikulin
2021-07-05 15:23                         ` Eli Zaretskii
2021-07-30 12:01     ` bug#12972: 24.3.50; Move `org-open-file' and associated code out of Org mode Lars Ingebrigtsen
2021-07-30 12:24       ` Maxim Nikulin
2021-07-30 12:42         ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83zgv2gpdq.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=12972@debbugs.gnu.org \
    --cc=manikulin@gmail.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).