From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "J.P." Newsgroups: gmane.emacs.bugs Subject: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C stack overflow Date: Tue, 29 Mar 2022 12:44:34 -0700 Message-ID: <87czi435nh.fsf@neverwas.me> References: <78459EAB-314B-4122-8E3B-7F82685D0DBA@acm.org> <83a6da9vm8.fsf@gnu.org> <87r16m46uf.fsf@neverwas.me> <4DA2DB05-D902-42DF-860D-87617FBB74C8@acm.org> <83k0cc907r.fsf@gnu.org> <5A8EE4CF-6F5E-4119-8765-8E301E2BE935@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22133"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: fernandodemorais.jf@gmail.com, bandali@gnu.org, 54458@debbugs.gnu.org To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Mar 29 21:45:54 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1nZHmr-0005WC-CX for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 29 Mar 2022 21:45:53 +0200 Original-Received: from localhost ([::1]:37264 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nZHmq-0005QC-Ct for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 29 Mar 2022 15:45:52 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:57452) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nZHm2-00052T-8f for bug-gnu-emacs@gnu.org; Tue, 29 Mar 2022 15:45:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39758) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nZHm1-0001QO-Va for bug-gnu-emacs@gnu.org; Tue, 29 Mar 2022 15:45:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nZHm1-000524-TM for bug-gnu-emacs@gnu.org; Tue, 29 Mar 2022 15:45:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Mar 2022 19:45:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54458 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 54458-submit@debbugs.gnu.org id=B54458.164858309519317 (code B ref 54458); Tue, 29 Mar 2022 19:45:01 +0000 Original-Received: (at 54458) by debbugs.gnu.org; 29 Mar 2022 19:44:55 +0000 Original-Received: from localhost ([127.0.0.1]:33655 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nZHlo-00051N-Iz for submit@debbugs.gnu.org; Tue, 29 Mar 2022 15:44:55 -0400 Original-Received: from mail-108-mta122.mxroute.com ([136.175.108.122]:36109) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nZHll-000517-T3 for 54458@debbugs.gnu.org; Tue, 29 Mar 2022 15:44:46 -0400 Original-Received: from filter006.mxroute.com ([140.82.40.27] 140.82.40.27.vultrusercontent.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta122.mxroute.com (ZoneMTA) with ESMTPSA id 17fd735700e000fe85.002 for <54458@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Tue, 29 Mar 2022 19:44:37 +0000 X-Zone-Loop: 07618b2db10de7c118a92d53e674cd42f68ec6ced785 X-Originating-IP: [140.82.40.27] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=drP0MC8BBgBj0WOIRfkYqsSCG5ayBSa/Y3BqqOJR51k=; b=Eo9C2pKFtpjJQXPI9SLHR5uY9A IFzAU6CKg04F0OWGTCgGqxsBxy/eSfzQUFL4K/Hr+uvbhpVcF+8ssYop6BtxLNT/pBknE345ytkwl tA2ZnHx2qZctUvloEVj8/wiczRrppJaDfTmcI301+QOr1pN7jguvE8HTLdkcgQbHLcqJAAeZ0OzwZ /EjikuhT7EE5s8fJFi7rfemhqvNNXvBvM1H1M7RBcocNpDw8Xp8YykdfNyHZn/mfKVbY+UZEcblXT FrkOYf1OrF4SvwQ0hnmhASH8QOdlz43U/gwqgWiByRcYnsq6oLRakbMf1Psgz7P7emjX/SxGg8j8j IJISVvsA==; In-Reply-To: <5A8EE4CF-6F5E-4119-8765-8E301E2BE935@acm.org> ("Mattias =?UTF-8?Q?Engdeg=C3=A5rd?="'s message of "Tue, 29 Mar 2022 19:47:52 +0200") X-AuthUser: masked@neverwas.me X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:229073 Archived-At: Mattias Engdeg=C3=A5rd writes: > Although it seems reasonable to require that filter functions abstain > from sending more data to the process, I think "app makers" (those of us building on Emacs as a platform) need a solid, authoritative pattern to mimic. What we at ERC are trying with our test server is to invert this "reactor pattern" by limiting the role of the filter to that of "reconstitutor of application frames." When one or more complete protocol frames arrives (in our case, CRLF delimited), it enqueues them and returns, perhaps after stashing any residual bytes for the next invocation. [1] Then, concurrently, we have our main handler/dispatcher loop, which is started by a specific sentinel event. It peeks at the queue and then maybe dispatches a method/reply handler or maybe handles housekeeping instead. The key for app makers, I think, is that we regain control by being free to deal with complete messages (remote "method calls" or "return values," logically) at a time and place of our choosing, rather than being forced to the dance to the tune of the selector. > there may be another way: preventing re-entering process-send calls > from recursing further. > > Attached is a proof of concept: if process-send calls are invoked when > another activation already exists, just enqueue the data and let the > previous activation deal with the actual transmission. That nips the > recursion in the buds. This seems an ingenious way of helping problematic code that already exists. I'll give it a whirl just for fun. (But alas, I know nothing.) > Of course, one reason to make the change in ERC is that it would fix the > problem in all Emacs versions, not just 29. You mean make the change by abstaining from the antipattern, right? I think ERC has no choice but to do just that because we're an ELPA package supporting multiple versions of Emacs. [1] https://git.neverwas.me/repos/erc-v3/tree/test/erc-d/erc-d.el?id=3Df1af= 52#n442