From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: emacs-29 8bf4cdcf79: Avoid recursive process filters in lisp/jsonrpc.el (bug#60088) Date: Sun, 18 Dec 2022 04:08:42 +0000 Message-ID: References: <167118072395.30479.8819833637573037468@vcs2.savannah.gnu.org> <20221216085204.43B07C04961@vcs2.savannah.gnu.org> <87h6xufv4v.fsf@neverwas.me> <877cypbth9.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000004abcce05f01257b2" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37624"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "F. Jason Park" , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 18 05:08:29 2022 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 1p6kyS-0009bN-VH for ged-emacs-devel@m.gmane-mx.org; Sun, 18 Dec 2022 05:08:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p6kxZ-0006OP-My; Sat, 17 Dec 2022 23:07:33 -0500 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 1p6kxY-0006OB-5I for emacs-devel@gnu.org; Sat, 17 Dec 2022 23:07:32 -0500 Original-Received: from mail-oa1-x2e.google.com ([2001:4860:4864:20::2e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p6kxV-0005R2-SK for emacs-devel@gnu.org; Sat, 17 Dec 2022 23:07:31 -0500 Original-Received: by mail-oa1-x2e.google.com with SMTP id 586e51a60fabf-14455716674so7972496fac.7 for ; Sat, 17 Dec 2022 20:07:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=94kJrS5ifPdCkqukmpaLYSSNwiEkM+GIP4njT26ekK4=; b=othmXRWT6AFZ5FpKTOpl1p+xHTN7cV4aKIxXEDAOjMp7ANtlRsm3Ks9Kl1ajAnDpcs 2njT1x5JbivGucIVY5E2vZDlOgMhnVei1hVoTZgsD+jmY+WmfaFcjp/tzb/iUSC+kZmP YrgnuTj12gN0rowmf9cRyvlXUjM12cJdgPWF/S4CP3OnG8EbQ0JTO1Kt1oDZ5AQHZ2DX OyQkCz73aYLoA8H/SAM7smcw4lHSzhIbMCjAslo8JXqmlQP6S5Z64U7osg5HFzxiDM+Y 4tXUb1JkcF6VOcAvGFXh02BWam538hv7q5oQkJg5kh5MbM/VnucbHXxRPzbQaX94PE7O 8u0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=94kJrS5ifPdCkqukmpaLYSSNwiEkM+GIP4njT26ekK4=; b=Cw/Xq4/yrlT+adCqhazKHn4/99WKFMMCA80BvYxOxbC+/D2AU8CqnQP0Y0p5geUGD7 TVedobdLZbBXommrlyUCrci2NcEpFljjbCo4Bi9IMwb4TLOsHBL4h4N3V0h974w4/Ptm B3OseRVV02pYdGZ8/cuUHvdGj2RUzf2czshhyrFmOm22L9MzUIxH3c/Xt0jFCGKGBWoi z3xynBRM1MnxnZNPq/u6gDd9tw7rZSq40Ziwf5c91cp2X9jgqLAwrDfYFeD/Scj9OBov kGJqw62EY4LjelStqlm0j1N15JLJmHdUSL9vn2EN4vxfGpExtfZRV8HyRUWcvAN1pITA 2QIw== X-Gm-Message-State: AFqh2kqvsaocvcwEqhq2O0skO7mDgrZ/bbokr20Ar2vmdI88UtZtIfZ7 k1b6oUoLY0ngISdVaTk4OIjgcN9M+5T2LydRchu3elnM X-Google-Smtp-Source: AMrXdXtaUt58AAN8w9A5vr+vkElf7LcMf5H+S/Ok23uauBi2myDTmMEuKl1LjdE53FQDyuaLN4E7bDAFCME7kmDlT7s= X-Received: by 2002:a05:6870:3116:b0:143:7889:c525 with SMTP id v22-20020a056870311600b001437889c525mr748035oaa.171.1671336448145; Sat, 17 Dec 2022 20:07:28 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2001:4860:4864:20::2e; envelope-from=joaotavora@gmail.com; helo=mail-oa1-x2e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:301598 Archived-At: --0000000000004abcce05f01257b2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Dec 18, 2022 at 1:57 AM Stefan Monnier wrote: > I guess you can see it that way too. So there are two ways to solve > > this: > > > > * only process-send-input in process filters makes sense > > * all but process-send-input in process filters makes sense > > I assume you meant to write `process-send-string`, but I don't know what > you mean by the above (I understand neither bullets). > Yes, it's process-send-string. I talked earlier about how I think sit-for and accept-process-output are two primitives that could just error when called from within a process filter, because there's no possible reasonable use for them, because they lead to recursive filters and recursive filters are arguably "unreasonable". But process-send-string (without output-acceptance) in a filter makes sense. That's the first bullet. The other bullet is that a-p-output and sit-for and even recursive filters may make sense (if you know what you are doing, i suppose), but the common case of sending a follow up message to a process (as a direct consequence of the output just received) should _not_ be handled with an in-filter p-s-string, but with something else, like the run-at-timer idea. In that case we can keep process-send-string's output acceptance. > > I'm more into of the first persuasion, but I think it shouldn't allow > > output to be accepted when called from within a process filter. > > Indeed, as a general rule doing a "blocking wait", such as > `accept-process-output` from within async code (process filter, timer, > etc..) is generally undesirable. > I agree, but process-send-string is never blocking, is it? And anyway if we go your 'spawn' or 'run-asap' way, we don't need to change process-send-string's output-acceptance semantics at all. Jo=C3=A3o --0000000000004abcce05f01257b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Dec 18, 2022 at 1:57 AM Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I guess you can see it that way too.=C2=A0 So there are two ways to so= lve
> this:
>
> * only process-send-input in process filters makes sense
> * all but process-send-input in process filters makes sense

I assume you meant to write `process-send-string`, but I don't know wha= t
you mean by the above (I understand neither bullets).
=
Yes, it's process-send-string.=C2=A0 I talked earlier ab= out how I think sit-for and
accept-process-output are two pr= imitives that could just error when
called from within a pro= cess filter, because there's no possible reasonable
use for t= hem, because they lead to recursive filters and recursive filters
are arguably "unreasonable".=C2=A0 But process-send-string (with= out
output-acceptance) in a filter makes sense.=C2=A0 That&#= 39;s the first bullet.

The other bullet is tha= t a-p-output and sit-for and even recursive filters may
make= sense (if you know what you are doing, i suppose), but the common
case of sending a follow up message to a process (as a direct consequence=
of the output just received) should _not_ be handled with a= n in-filter p-s-string,
but with something else, like the run-at-= timer idea.=C2=A0 In that case we can keep
process-send-string= 9;s output acceptance.
=C2=A0
> I'm more into of the first persuasion, but I think it shouldn'= t allow
> output to be accepted when called from within a process filter.

Indeed, as a general rule doing a "blocking wait", such as
`accept-process-output` from within async code (process filter, timer,
etc..) is generally undesirable.

I agre= e, but process-send-string is never blocking, is it?=C2=A0 And anyway
<= /div>
if we go your 'spawn' or 'run-asap' way, we don&#= 39;t need to change
process-send-string's output-accepta= nce semantics at all.

Jo=C3=A3o
--0000000000004abcce05f01257b2--