From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Markus Triska Newsgroups: gmane.emacs.bugs Subject: bug#33747: 26.1; process-send-string exceeds max-specpdl-size Date: Fri, 14 Dec 2018 19:50:39 +0100 Message-ID: <874lbgeydc.fsf@metalevel.at> References: <87bm5o2e3u.fsf@metalevel.at> <83o99oeyuz.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1544813352 29941 195.159.176.226 (14 Dec 2018 18:49:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 14 Dec 2018 18:49:12 +0000 (UTC) User-Agent: Emacs/24.5 Cc: 33747@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Dec 14 19:49:08 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gXsWJ-0007bM-Ku for geb-bug-gnu-emacs@m.gmane.org; Fri, 14 Dec 2018 19:49:07 +0100 Original-Received: from localhost ([::1]:35037 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gXsYP-00057k-Q1 for geb-bug-gnu-emacs@m.gmane.org; Fri, 14 Dec 2018 13:51:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60601) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gXsYG-00057e-16 for bug-gnu-emacs@gnu.org; Fri, 14 Dec 2018 13:51:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gXsYA-0005Yl-E7 for bug-gnu-emacs@gnu.org; Fri, 14 Dec 2018 13:51:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:44291) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gXsYA-0005YS-9b for bug-gnu-emacs@gnu.org; Fri, 14 Dec 2018 13:51:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gXsYA-0006j6-1c for bug-gnu-emacs@gnu.org; Fri, 14 Dec 2018 13:51:02 -0500 X-Loop: help-debbugs@gnu.org In-Reply-To: <87bm5o2e3u.fsf@metalevel.at> Resent-From: Markus Triska Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Dec 2018 18:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33747 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 33747-submit@debbugs.gnu.org id=B33747.154481344525834 (code B ref 33747); Fri, 14 Dec 2018 18:51:02 +0000 Original-Received: (at 33747) by debbugs.gnu.org; 14 Dec 2018 18:50:45 +0000 Original-Received: from localhost ([127.0.0.1]:48549 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gXsXr-0006iZ-Hl for submit@debbugs.gnu.org; Fri, 14 Dec 2018 13:50:45 -0500 Original-Received: from metalevel.at ([78.46.218.83]:45080) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gXsXp-0006iR-Hi for 33747@debbugs.gnu.org; Fri, 14 Dec 2018 13:50:42 -0500 Original-Received: by metalevel.at (Postfix, from userid 1000) id D3828A122B; Fri, 14 Dec 2018 19:50:39 +0100 (CET) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:153458 Archived-At: Eli Zaretskii writes: > AFAIK, process-send-string is a blocking function: it cannot return > before the entire string was sent. Yes indeed. However, the C function send_process internally calls wait_reading_process_output, and this may again invoke the filter! What I find surprising is that this call of wait_reading_process_output is not limited to the process whose output queue is full, i.e., the one for which process-send-string was actually invoked. Would it work to limit it to that process, or could there be an alternative means to prevent reading from other processes in that case? It would be very useful in such situations where I simply want to send, and not read anything.