From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: call-process should not block process filters from running Date: Mon, 03 Jul 2023 21:51:50 +0300 Message-ID: <834jmkn7zt.fsf@gnu.org> References: <83cz1fvjef.fsf@gnu.org> <83h6qnpieb.fsf@gnu.org> <837criq321.fsf@gnu.org> <87r0pprhfd.fsf@catern.com> <87o7kts4ba.fsf@yahoo.com> <87lefwrif5.fsf@catern.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6414"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: sbaugh@catern.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 03 20:51:34 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qGOe6-0001Um-9X for ged-emacs-devel@m.gmane-mx.org; Mon, 03 Jul 2023 20:51:34 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qGOdr-0001II-8O; Mon, 03 Jul 2023 14:51:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qGOdm-0001Hs-C7 for emacs-devel@gnu.org; Mon, 03 Jul 2023 14:51:14 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qGOdm-0004ye-0b; Mon, 03 Jul 2023 14:51:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=KA04/hCZ9/4feDyG27/TJp9R7n5UNPqxZjHIkTnTl7U=; b=khLUNeLTzXgZ PI2ujk7fX8GNkCUEdjI+Km6HMMpscFphqPH98JEMSZIFhYpJ3gPASGznRXxwO/Ki7Lc26FsB9H31V nkJ2O7SYYJBXba6eZX11lpqOLe3kppy+e4U7C6LMVSKv/Z+5KwnVvit92x0AiYoWs33Nr/Z9kL9zI xvcQRzQgbd34dU9mYEEOSYAqfBSTU8CUdCUI3K4H6YJQuGzqlzBKnc7vXfUiX22ZhnjGYGEwQvEG0 tDaZkEXi7vdeY2lfNsEfaG9PueF3GXRmyRdPxwMHXYBGjlP+vCBl/PkKGkMVKgqcBKlunysAxQU9e D+MT+yhk84iz3bwkaNcjJA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qGOdl-0007yq-GP; Mon, 03 Jul 2023 14:51:13 -0400 In-Reply-To: <87lefwrif5.fsf@catern.com> (sbaugh@catern.com) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:307391 Archived-At: > From: sbaugh@catern.com > Date: Mon, 03 Jul 2023 13:53:02 -0400 > > > I don't recommend doing either from call_process: a lot of existing > > code relies on Lisp code not running inside calls to that function, > > and errors inside selection handlers will be signaled even if > > nothing's wrong with the process being called. > > Right, in the real patch this will be behind a new variable which code > can let-bind to explicitly opt-in to the new behavior, as Eli suggested. > So existing code won't see behavior changes. I'm not sure the new code should call swallow_events, even if protected by some variable. We will be giving people a too-long rope to hang themselves. It is unreasonable to assume Lisp programmers will be able to decide when to allow this and when not to, given the complexities. Why do we need to jump through all the hoops right at the beginning? Why not make a small step forward and see if this experiment is more useful than it is dangerous? Then we could decide whether to make the next step, and how. No one said that pasting into Emacs while a subprocess runs is the most important capability to enable. I'd first make sure the user can type at the keyboard without adverse effects. Let's not over-engineer this without a sufficient justification. > > Also, you should at least check that call_process is reentrant: it > > must be able to handle calls to itself made by any timers or selection > > handlers that run within the process input loop, with the processes > > being called completing in any order. > > Hm, good point. Right now in call_process there's: > > if (synch_process_pid) > error ("call-process invoked recursively"); > > So it's at least "safe" to call recursively, since it explicitly errors > rather than having undefined behavior. But erroring in this way is > probably not desirable. > > I can make it re-entrant. synch_process_pid is itself a global, so > that's the place to start. > > Eli, your thoughts? Is this more complicated than you were thinking? I don't see how it will be more complicated to have a list or array of PIDs instead of just one value. This "complication" is nothing compared to the job of rewriting call-process with all its quirks in Lisp, even if you ignore the problems and loss of performance we'd need to sustain to decode and insert the output in Lisp rather than in C.