From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Mendler Newsgroups: gmane.emacs.bugs Subject: bug#48118: 27.1; 28; Only first process receives output with multiple running processes Date: Fri, 30 Apr 2021 17:39:35 +0200 Message-ID: References: <64c194f9-b984-adaa-d5fd-86aa3ed3833a@daniel-mendler.de> <83wnsjc0vd.fsf@gnu.org> <83tunnc0hz.fsf@gnu.org> <83pmybc03l.fsf@gnu.org> <83o8dvbyyz.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28685"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 48118@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Apr 30 17:40:15 2021 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 1lcVFW-0007Mi-BG for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 30 Apr 2021 17:40:14 +0200 Original-Received: from localhost ([::1]:51890 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lcVFV-0002pL-Ec for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 30 Apr 2021 11:40:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47640) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lcVFK-0002oB-Tb for bug-gnu-emacs@gnu.org; Fri, 30 Apr 2021 11:40:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48047) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lcVFK-0005Rr-LH for bug-gnu-emacs@gnu.org; Fri, 30 Apr 2021 11:40:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lcVFK-0004Vp-GT for bug-gnu-emacs@gnu.org; Fri, 30 Apr 2021 11:40:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 30 Apr 2021 15:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48118 X-GNU-PR-Package: emacs Original-Received: via spool by 48118-submit@debbugs.gnu.org id=B48118.161979718517317 (code B ref 48118); Fri, 30 Apr 2021 15:40:02 +0000 Original-Received: (at 48118) by debbugs.gnu.org; 30 Apr 2021 15:39:45 +0000 Original-Received: from localhost ([127.0.0.1]:59593 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcVF3-0004VE-C1 for submit@debbugs.gnu.org; Fri, 30 Apr 2021 11:39:45 -0400 Original-Received: from server.qxqx.de ([178.63.65.180]:58055 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcVF1-0004V2-No for 48118@debbugs.gnu.org; Fri, 30 Apr 2021 11:39:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject: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=HbuKfXyGekFq6RPyNyjMxFCIqaNyGBsrZq5fgVrolhI=; b=NKOjDS4LLMXRMmOmICwoRBO/e8 jiDPl5UwK7Cu62C4DqRc06a3sIxw/tBbUEiEz43ulpiP4bS9hvM8CQARndUtTRhR1gY0SRiV3gtrF VMII/tOHxRPbHA2F0GzyN64qJ0lqdX5kiuSqwXp206bCiEUu/kvtNv8VfQKv7NXSqh/4=; In-Reply-To: <83o8dvbyyz.fsf@gnu.org> Content-Language: en-US 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:205266 Archived-At: On 4/30/21 4:59 PM, Eli Zaretskii wrote: > That's not what I meant. I meant that if your Lisp program launches a > subprocess that is known to spill huge amounts of output at high rate, > and you don't want to starve other subprocesses, your filter function > can stop the process from time to time to give others an opportunity > to have their outputs read. This is true. However I expect Emacs to do that for me. I see the situation like this - I have multiple packages creating processes and competing for runtime. Then I expect Emacs to take some kind of preemptive role and ensure that none of the processes misbehaves. However one can also take the standpoint that each process should try to behave well by itself and should be scheduled explicitly; Emacs should stay out of this business. >>>> since the underlying Emacs handling of asynchronous processes is >>>> unable to read from two processes at once? >>> >>> No. The problem is not the _ability_ to read from more than one >>> subprocess -- the ability does exist. The problem is that doing so >>> would run afoul of other scenarios. >> >> Which scenarios break? > > For example, if the filter function call accept-process-output. Or > does anything else that changes output from which processes is or > isn't available. Does this necessarily prevent scheduling? I interpret `accept-process-output` as a function which prioritizes a process, but I am unsure if this makes it impossible to implement additional scheduling. > What does this mean, exactly? Which quantity should be doled in a > round-robin fashion? bytes read from the processes? something else? > > If the bytes read, then how do you suggest to handle two processes > which produce output at very different rates? For example bytes read or time spent to handle a process (time spent in the filter function?). If a process has eaten up its time it has to wait until it gets scheduled next. If you have two process with very different rates, the slow process may not use up its allotted time slot and the faster process is still allowed to run. >> I am not happy with the argument that Emacs cannot do any better than >> stopping the second process and only handle the first process. > > I'm not saying that Emacs cannot do that, I'm trying to understand > what that would mean in practice. Actually I would also like to understand what the best process handling looks like. When I stumbled over this issue, it astonished me that Emacs does not seem to do any scheduling at all and handles only a single process. As far as I know other language runtimes handle this problem differently, attempting some kind of scheduling. What is the reason for the current behavior? Is it predictability? If I understand correctly, Emacs always reads from the first process. If data arrives, Emacs does not read from the second processes at all. Only if no data is available from the first process, the second process is handled. Is it like this?