From unknown Thu Jun 19 14:05:18 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#48118 <48118@debbugs.gnu.org> To: bug#48118 <48118@debbugs.gnu.org> Subject: Status: 27.1; 28; Only first process receives output with multiple running processes Reply-To: bug#48118 <48118@debbugs.gnu.org> Date: Thu, 19 Jun 2025 21:05:18 +0000 retitle 48118 27.1; 28; Only first process receives output with multiple ru= nning processes reassign 48118 emacs submitter 48118 Daniel Mendler severity 48118 normal tag 48118 fixed thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 30 09:44:29 2021 Received: (at submit) by debbugs.gnu.org; 30 Apr 2021 13:44:29 +0000 Received: from localhost ([127.0.0.1]:57946 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcTRV-00017d-3D for submit@debbugs.gnu.org; Fri, 30 Apr 2021 09:44:29 -0400 Received: from lists.gnu.org ([209.51.188.17]:54342) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcTRT-00017W-MV for submit@debbugs.gnu.org; Fri, 30 Apr 2021 09:44:27 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46090) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lcTRS-0007zY-Cu for bug-gnu-emacs@gnu.org; Fri, 30 Apr 2021 09:44:27 -0400 Received: from server.qxqx.de ([2a01:4f8:121:346::180]:39089 helo=mail.qxqx.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lcTRO-0004gw-Dj for bug-gnu-emacs@gnu.org; Fri, 30 Apr 2021 09:44:25 -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:MIME-Version:Date: Message-ID:Subject:From:To:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=R7d1fHyr7lOtHjV0iDEA1AceXEz+str+c4Ia5aNhYtM=; b=ITmDZfGvaEQUyMEnSFMMFHAKZ0 dfNZ7mP/Y/0cZjjlbjuAbISbDKOZK6CDH4bsR0q7/HI8zCare4RshPqYJVNe+Tfz7YBw76Jr/DZM4 V6EbhekCfJPeyTwXdJMmnkNQlKIu5jsPphCsiADh4AGD3xXOxiwHR1X0i7YVNIr+vmr4=; To: bug-gnu-emacs@gnu.org From: Daniel Mendler Subject: 27.1; 28; Only first process receives output with multiple running processes Message-ID: <64c194f9-b984-adaa-d5fd-86aa3ed3833a@daniel-mendler.de> Date: Fri, 30 Apr 2021 15:44:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=2a01:4f8:121:346::180; envelope-from=mail@daniel-mendler.de; helo=mail.qxqx.de X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) When running multiple asynchronous processes only the output of the first process is handled. This happens when the first process continously produces a huge amount of output, for example when running `ripgrep` as done by my `consult-ripgrep` command (part of my Consult package). Then Emacs is stuck handling the output of the first process. The output of the second process is not read until the first process is terminated. I expect Emacs to treat the running processes fairly. The issue also occurs if a :filter function is specified. Both Emacs 27 and 28 are affected. Minimal reproducible example by @jakanakaevangeli: (progn (setq pa (make-process :name "yes-a" :command '("yes") :connection-type 'pipe :buffer (setq a (generate-new-buffer " *a*")))) (setq pb (make-process :name "yes-b" :command '("yes") :connection-type 'pipe :buffer (setq b (generate-new-buffer " *b*")))) (run-at-time 1 1 (lambda () (message "size a: %s\nsize b: %s" (buffer-size a) (buffer-size b))))) Original bug discussions: https://github.com/minad/consult/issues/272 https://github.com/minad/consult/pull/297 From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 30 10:18:21 2021 Received: (at 48118) by debbugs.gnu.org; 30 Apr 2021 14:18:21 +0000 Received: from localhost ([127.0.0.1]:59385 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcTyE-0002P9-LW for submit@debbugs.gnu.org; Fri, 30 Apr 2021 10:18:21 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47310) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcTy9-0002Ou-Ng for 48118@debbugs.gnu.org; Fri, 30 Apr 2021 10:18:17 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47704) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lcTy3-0007zZ-PE; Fri, 30 Apr 2021 10:18:07 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4618 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lcTy3-00020H-5h; Fri, 30 Apr 2021 10:18:07 -0400 Date: Fri, 30 Apr 2021 17:17:58 +0300 Message-Id: <83wnsjc0vd.fsf@gnu.org> From: Eli Zaretskii To: Daniel Mendler In-Reply-To: <64c194f9-b984-adaa-d5fd-86aa3ed3833a@daniel-mendler.de> (message from Daniel Mendler on Fri, 30 Apr 2021 15:44:17 +0200) Subject: Re: bug#48118: 27.1; 28; Only first process receives output with multiple running processes References: <64c194f9-b984-adaa-d5fd-86aa3ed3833a@daniel-mendler.de> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 48118 Cc: 48118@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Daniel Mendler > Date: Fri, 30 Apr 2021 15:44:17 +0200 > > When running multiple asynchronous processes only the output of the > first process is handled. This happens when the first process > continously produces a huge amount of output, for example when running > `ripgrep` as done by my `consult-ripgrep` command (part of my Consult > package). Then Emacs is stuck handling the output of the first process. > The output of the second process is not read until the first process is > terminated. I expect Emacs to treat the running processes fairly. Why can't you call stop-process from your sentinel function(s) to avoid the problem? From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 30 10:23:47 2021 Received: (at 48118) by debbugs.gnu.org; 30 Apr 2021 14:23:47 +0000 Received: from localhost ([127.0.0.1]:59401 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcU3X-0002Xy-A3 for submit@debbugs.gnu.org; Fri, 30 Apr 2021 10:23:47 -0400 Received: from server.qxqx.de ([178.63.65.180]:53853 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcU3S-0002Xh-JG for 48118@debbugs.gnu.org; Fri, 30 Apr 2021 10:23:45 -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=b8u7W6cdQ4dh5joQ7VGuK2gocpqHKotcit3LRfn+u6o=; b=puXH0wSb6tkbW+xPuUEQJtv/wy tiWl9dGCiPGkVMJe6VrfvgCHOfevtZPY9THarl3PY9MDbzLbUdyXX72UBzFUTmJqp0wuu3e8Bjcs5 z40xMMAbmPJLfgN3NUm+vMCcB31waUydK3Dcfv8eUcdIvLuWvoW5oc4VhPLD+YqXfyWU=; Subject: Re: bug#48118: 27.1; 28; Only first process receives output with multiple running processes To: Eli Zaretskii References: <64c194f9-b984-adaa-d5fd-86aa3ed3833a@daniel-mendler.de> <83wnsjc0vd.fsf@gnu.org> From: Daniel Mendler Message-ID: <09261dcc-92e6-0c4e-e692-7e48979b6b91@daniel-mendler.de> Date: Fri, 30 Apr 2021 16:23:34 +0200 MIME-Version: 1.0 In-Reply-To: <83wnsjc0vd.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 48118 Cc: 48118@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/30/21 4:17 PM, Eli Zaretskii wrote: >> When running multiple asynchronous processes only the output of the >> first process is handled. This happens when the first process >> continously produces a huge amount of output, for example when running >> `ripgrep` as done by my `consult-ripgrep` command (part of my Consult >> package). Then Emacs is stuck handling the output of the first process. >> The output of the second process is not read until the first process is >> terminated. I expect Emacs to treat the running processes fairly. > > Why can't you call stop-process from your sentinel function(s) to > avoid the problem? What do you mean? I don't want to stop the processes. I want to have them running asynchronously and concurrently and Emacs should receive the incoming data of both processes. When I have to stop the processes the benefit of running the processes asynchronously is lost. ------ I forgot to append the system information to the report. In GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.5, cairo version 1.16.0) of 2021-02-09, modified by Debian built on 3df710f593d9 Repository revision: b0229d4bbaea7fcddffced393512c650212830db Repository branch: deb/emacs/d/sid/master Windowing system distributor 'The X.Org Foundation', version 11.0.12004000 System Description: Debian GNU/Linux 10 (buster) Configured using: 'configure --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --enable-libsystemd --with-pop=yes --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/27.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/27.1/site-lisp:/usr/share/emacs/site-lisp --with-sound=alsa --without-gconf --with-mailutils --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --enable-libsystemd --with-pop=yes --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/27.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/27.1/site-lisp:/usr/share/emacs/site-lisp --with-sound=alsa --without-gconf --with-mailutils --with-cairo --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars 'CFLAGS=-g -O2 -fdebug-prefix-map=/emacs/emacs=. -fstack-protector-strong -Wformat -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro' Configured features: XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON PDUMPER LCMS2 GMP From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 30 10:26:17 2021 Received: (at 48118) by debbugs.gnu.org; 30 Apr 2021 14:26:17 +0000 Received: from localhost ([127.0.0.1]:59405 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcU5w-0002bl-RT for submit@debbugs.gnu.org; Fri, 30 Apr 2021 10:26:16 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49192) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcU5w-0002ba-0w for 48118@debbugs.gnu.org; Fri, 30 Apr 2021 10:26:16 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47848) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lcU5q-0003yG-KX; Fri, 30 Apr 2021 10:26:10 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1132 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lcU5n-0002if-36; Fri, 30 Apr 2021 10:26:08 -0400 Date: Fri, 30 Apr 2021 17:26:00 +0300 Message-Id: <83tunnc0hz.fsf@gnu.org> From: Eli Zaretskii To: mail@daniel-mendler.de In-Reply-To: <83wnsjc0vd.fsf@gnu.org> (message from Eli Zaretskii on Fri, 30 Apr 2021 17:17:58 +0300) Subject: Re: bug#48118: 27.1; 28; Only first process receives output with multiple running processes References: <64c194f9-b984-adaa-d5fd-86aa3ed3833a@daniel-mendler.de> <83wnsjc0vd.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 48118 Cc: 48118@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 30 Apr 2021 17:17:58 +0300 > From: Eli Zaretskii > Cc: 48118@debbugs.gnu.org > > Why can't you call stop-process from your sentinel function(s) to > avoid the problem? Sorry, I meant filter functions, of course. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 30 10:31:05 2021 Received: (at 48118) by debbugs.gnu.org; 30 Apr 2021 14:31:05 +0000 Received: from localhost ([127.0.0.1]:59417 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcUAa-0002k4-Tw for submit@debbugs.gnu.org; Fri, 30 Apr 2021 10:31:05 -0400 Received: from server.qxqx.de ([178.63.65.180]:55967 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcUAY-0002jZ-Pj for 48118@debbugs.gnu.org; Fri, 30 Apr 2021 10:31:03 -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=gBXXTrvNlb4x4EiA/ryaHJ59sFoBVDSuHXbIK43HhwY=; b=N5jMQ6Y+D8O/Z8BEarGlWp0abl PZrUeqm29bzjXzjNrG6qUHm3uNGCQ00VgtJ4G0s1VJ70jxeoVeHg5MdPRNetMYllEUETfPRdqw00N Lg3G87nIlMgMvO71/faVWTOc5yH7ktqCWGMxg+NFSy9UnTiQvQih+yGDXkoSfGDIqu3U=; Subject: Re: bug#48118: 27.1; 28; Only first process receives output with multiple running processes To: Eli Zaretskii References: <64c194f9-b984-adaa-d5fd-86aa3ed3833a@daniel-mendler.de> <83wnsjc0vd.fsf@gnu.org> <83tunnc0hz.fsf@gnu.org> From: Daniel Mendler Message-ID: Date: Fri, 30 Apr 2021 16:30:54 +0200 MIME-Version: 1.0 In-Reply-To: <83tunnc0hz.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 48118 Cc: 48118@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/30/21 4:26 PM, Eli Zaretskii wrote: >> Date: Fri, 30 Apr 2021 17:17:58 +0300 >> From: Eli Zaretskii >> Cc: 48118@debbugs.gnu.org >> >> Why can't you call stop-process from your sentinel function(s) to >> avoid the problem? > > Sorry, I meant filter functions, of course. So you say I should repeatedly stop the current process in the filter function in order to allow the other process to take precedence, since the underlying Emacs handling of asynchronous processes is unable to read from two processes at once? This does not sound like a good solution to me. What is preventing Emacs from treating multiple processes fairly? From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 30 10:31:25 2021 Received: (at 48118) by debbugs.gnu.org; 30 Apr 2021 14:31:25 +0000 Received: from localhost ([127.0.0.1]:59420 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcUAv-0002kc-4k for submit@debbugs.gnu.org; Fri, 30 Apr 2021 10:31:25 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50088) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcUAt-0002kP-Fp for 48118@debbugs.gnu.org; Fri, 30 Apr 2021 10:31:23 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47919) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lcUAn-00074q-WF; Fri, 30 Apr 2021 10:31:18 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1448 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lcUAm-0007k2-9y; Fri, 30 Apr 2021 10:31:17 -0400 Date: Fri, 30 Apr 2021 17:31:09 +0300 Message-Id: <83sg37c09e.fsf@gnu.org> From: Eli Zaretskii To: Daniel Mendler In-Reply-To: <09261dcc-92e6-0c4e-e692-7e48979b6b91@daniel-mendler.de> (message from Daniel Mendler on Fri, 30 Apr 2021 16:23:34 +0200) Subject: Re: bug#48118: 27.1; 28; Only first process receives output with multiple running processes References: <64c194f9-b984-adaa-d5fd-86aa3ed3833a@daniel-mendler.de> <83wnsjc0vd.fsf@gnu.org> <09261dcc-92e6-0c4e-e692-7e48979b6b91@daniel-mendler.de> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 48118 Cc: 48118@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 48118@debbugs.gnu.org > From: Daniel Mendler > Date: Fri, 30 Apr 2021 16:23:34 +0200 > > > Why can't you call stop-process from your sentinel function(s) to > > avoid the problem? > > What do you mean? I don't want to stop the processes. I want to have > them running asynchronously and concurrently and Emacs should receive > the incoming data of both processes. When I have to stop the processes > the benefit of running the processes asynchronously is lost. So let's talk about this in more detail, okay? First, what does "fairness" mean in this context? Given that there are multiple simultaneous asynchronous subprocesses that produce output at different rates and consume CPU at different levels, what would it mean for Emacs to be "fair"? Second, suppose we have multiple ripgrep subprocesses running, and Emacs will somehow read from each one of them in a round-robin fashion: what and how do you expect the user to do to handle the results of all those subprocesses simultaneously and "fairly"? From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 30 10:34:56 2021 Received: (at 48118) by debbugs.gnu.org; 30 Apr 2021 14:34:56 +0000 Received: from localhost ([127.0.0.1]:59427 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcUEK-0002pe-Li for submit@debbugs.gnu.org; Fri, 30 Apr 2021 10:34:56 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50884) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcUEJ-0002pS-Go for 48118@debbugs.gnu.org; Fri, 30 Apr 2021 10:34:56 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48002) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lcUEE-0008V9-9n; Fri, 30 Apr 2021 10:34:50 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1660 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lcUE7-0005IV-OE; Fri, 30 Apr 2021 10:34:47 -0400 Date: Fri, 30 Apr 2021 17:34:38 +0300 Message-Id: <83pmybc03l.fsf@gnu.org> From: Eli Zaretskii To: Daniel Mendler In-Reply-To: (message from Daniel Mendler on Fri, 30 Apr 2021 16:30:54 +0200) Subject: Re: bug#48118: 27.1; 28; Only first process receives output with multiple running processes References: <64c194f9-b984-adaa-d5fd-86aa3ed3833a@daniel-mendler.de> <83wnsjc0vd.fsf@gnu.org> <83tunnc0hz.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 48118 Cc: 48118@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 48118@debbugs.gnu.org > From: Daniel Mendler > Date: Fri, 30 Apr 2021 16:30:54 +0200 > > So you say I should repeatedly stop the current process in the filter > function in order to allow the other process to take precedence Yes. > 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. > me. What is preventing Emacs from treating multiple processes > fairly? I asked elsewhere what you mean by "fairly" in this context. But the general answer to your question is that Emacs knows nothing about the processes, their importance, their output rates, and the respective filter functions. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 30 10:45:41 2021 Received: (at 48118) by debbugs.gnu.org; 30 Apr 2021 14:45:41 +0000 Received: from localhost ([127.0.0.1]:59510 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcUOd-0003AD-5Z for submit@debbugs.gnu.org; Fri, 30 Apr 2021 10:45:41 -0400 Received: from server.qxqx.de ([178.63.65.180]:56285 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcUOb-0003A0-5l for 48118@debbugs.gnu.org; Fri, 30 Apr 2021 10:45:33 -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=cT+XHcynz2B8BbxLZsA6qcxV6cPuLkkwHKdjDp3KpzY=; b=JmxbkwzxHNg1FCSeCUDJaruoW5 hPz+UCPgojxgA5YE6LWPTMUWCuQ+ClOevu4CzGGUGM5qVxZ3FLLNlMRBn1INFOyQCoDH4XybsYEoT ulAm1CHyUnpgoqTH3dmpqxC3RSwtmTEu2sdBZ+YDjWBPjkHzTz6vUmaAn8NaNUodN6E8=; Subject: Re: bug#48118: 27.1; 28; Only first process receives output with multiple running processes To: Eli Zaretskii References: <64c194f9-b984-adaa-d5fd-86aa3ed3833a@daniel-mendler.de> <83wnsjc0vd.fsf@gnu.org> <83tunnc0hz.fsf@gnu.org> <83pmybc03l.fsf@gnu.org> From: Daniel Mendler Message-ID: Date: Fri, 30 Apr 2021 16:45:25 +0200 MIME-Version: 1.0 In-Reply-To: <83pmybc03l.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 48118 Cc: 48118@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) On 4/30/21 4:34 PM, Eli Zaretskii wrote: >> So you say I should repeatedly stop the current process in the filter >> function in order to allow the other process to take precedence > > Yes. This is not a good solution. What if I have multiple packages which read from asynchronous processes? Maybe I cannot control all of the processes and their scheduling. >> 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? >> me. What is preventing Emacs from treating multiple processes >> fairly? > > I asked elsewhere what you mean by "fairly" in this context. > > But the general answer to your question is that Emacs knows nothing > about the processes, their importance, their output rates, and the > respective filter functions. Okay good. How can I configure it such that two processes both populate their buffers in a round-robin fashion? > First, what does "fairness" mean in this context? Given that there > are multiple simultaneous asynchronous subprocesses that produce > output at different rates and consume CPU at different levels, what > would it mean for Emacs to be "fair"? > > Second, suppose we have multiple ripgrep subprocesses running, and > Emacs will somehow read from each one of them in a round-robin > fashion: what and how do you expect the user to do to handle the > results of all those subprocesses simultaneously and "fairly"? I agree with you that fairness is a difficult problem. But the problem is omnipresent at the os level. There you have scheduling problems in the io layer, in the process scheduling layer, in the memory management layer and so on. There is certainly some heuristic that one can apply. For example by comparing the amount of data produced by multiple processes one could decide which process is read next. Or one can use a deadline criterion. I am not happy with the argument that Emacs cannot do any better than stopping the second process and only handle the first process. If you don't want to hardcode the scheduling behavior there could be some pluggable scheduler. This would be better than having to write my own scheduling by hand for each `make-process` call. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 30 10:59:17 2021 Received: (at 48118) by debbugs.gnu.org; 30 Apr 2021 14:59:17 +0000 Received: from localhost ([127.0.0.1]:59526 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcUbt-0003UI-9P for submit@debbugs.gnu.org; Fri, 30 Apr 2021 10:59:17 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57414) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcUbr-0003U6-Ne for 48118@debbugs.gnu.org; Fri, 30 Apr 2021 10:59:16 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48706) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lcUbl-0006HR-MD; Fri, 30 Apr 2021 10:59:09 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3162 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lcUbk-00058W-LT; Fri, 30 Apr 2021 10:59:09 -0400 Date: Fri, 30 Apr 2021 17:59:00 +0300 Message-Id: <83o8dvbyyz.fsf@gnu.org> From: Eli Zaretskii To: Daniel Mendler In-Reply-To: (message from Daniel Mendler on Fri, 30 Apr 2021 16:45:25 +0200) Subject: Re: bug#48118: 27.1; 28; Only first process receives output with multiple running processes References: <64c194f9-b984-adaa-d5fd-86aa3ed3833a@daniel-mendler.de> <83wnsjc0vd.fsf@gnu.org> <83tunnc0hz.fsf@gnu.org> <83pmybc03l.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 48118 Cc: 48118@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 48118@debbugs.gnu.org > From: Daniel Mendler > Date: Fri, 30 Apr 2021 16:45:25 +0200 > > On 4/30/21 4:34 PM, Eli Zaretskii wrote: > >> So you say I should repeatedly stop the current process in the filter > >> function in order to allow the other process to take precedence > > > > Yes. > > This is not a good solution. What if I have multiple packages which read > from asynchronous processes? Maybe I cannot control all of the processes > and their scheduling. 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. > >> 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. > > But the general answer to your question is that Emacs knows nothing > > about the processes, their importance, their output rates, and the > > respective filter functions. > > Okay good. How can I configure it such that two processes both populate > their buffers in a round-robin fashion? 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? > 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. > If you don't want to hardcode the scheduling behavior there could be > some pluggable scheduler. This would be better than having to write my > own scheduling by hand for each `make-process` call. Please hold your horses, you are getting too far ahead of the discussion. I asked those questions for a reason: I think we cannot make any meaningful progress without answering them first. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 30 11:39:45 2021 Received: (at 48118) by debbugs.gnu.org; 30 Apr 2021 15:39:45 +0000 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 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=; Subject: Re: bug#48118: 27.1; 28; Only first process receives output with multiple running processes To: Eli Zaretskii 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> From: Daniel Mendler Message-ID: Date: Fri, 30 Apr 2021 17:39:35 +0200 MIME-Version: 1.0 In-Reply-To: <83o8dvbyyz.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 48118 Cc: 48118@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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? From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 30 11:58:23 2021 Received: (at 48118) by debbugs.gnu.org; 30 Apr 2021 15:58:24 +0000 Received: from localhost ([127.0.0.1]:59645 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcVX5-00078M-J8 for submit@debbugs.gnu.org; Fri, 30 Apr 2021 11:58:23 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43130) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcVX4-000786-F3 for 48118@debbugs.gnu.org; Fri, 30 Apr 2021 11:58:22 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:50072) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lcVWy-0003r3-HC; Fri, 30 Apr 2021 11:58:16 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2799 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lcVWw-0003Lm-1u; Fri, 30 Apr 2021 11:58:14 -0400 Date: Fri, 30 Apr 2021 18:58:06 +0300 Message-Id: <83bl9vbw8h.fsf@gnu.org> From: Eli Zaretskii To: Daniel Mendler In-Reply-To: (message from Daniel Mendler on Fri, 30 Apr 2021 17:39:35 +0200) Subject: Re: bug#48118: 27.1; 28; Only first process receives output with multiple running processes 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> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 48118 Cc: 48118@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 48118@debbugs.gnu.org > From: Daniel Mendler > Date: Fri, 30 Apr 2021 17:39:35 +0200 > > >> 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. A call to accept-process-output prioritizes a process only if it explicitly requests output from that single process. Which is not necessarily true in all cases. > > 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?). Bytes read has a problem when processes produce output a very different rates. Time spent to handle may (and usually does) mean the filter function does something expensive, it doesn't necessarily tell anything about the output from the subprocess. > 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. If you read the code, you will see this isn't what happens. What happens is that Emacs reads a chunk of output from the first process it sees ready, then it goes back and re-checks which processes are ready -- and in your scenario I think it again sees that the first process is ready. > 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? In your scenario, yes. It depends on how large is the output produced by a process in one go. I suggest to read the code of wait_reading_process_output, it has some non-trivial logic in this department. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 30 12:10:18 2021 Received: (at 48118) by debbugs.gnu.org; 30 Apr 2021 16:10:18 +0000 Received: from localhost ([127.0.0.1]:59677 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcVic-0001A8-Bk for submit@debbugs.gnu.org; Fri, 30 Apr 2021 12:10:18 -0400 Received: from chiru.no ([142.4.209.132]:51768) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcVia-00019x-GN for 48118@debbugs.gnu.org; Fri, 30 Apr 2021 12:10:16 -0400 Received: from localhost (BSN-77-156-43.static.siol.net [193.77.156.43]) by chiru.no (Postfix) with ESMTPSA id EF8EE128001B; Fri, 30 Apr 2021 16:10:14 +0000 (UTC) From: jakanakaevangeli@chiru.no To: Daniel Mendler Subject: Re: bug#48118: 27.1; 28; Only first process receives output with multiple running processes In-Reply-To: (message from Daniel Mendler on Fri, 30 Apr 2021 17:39:35 +0200) Date: Fri, 30 Apr 2021 18:15:16 +0200 Message-ID: <87pmyb6963.fsf@miha-pc> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 48118 Cc: eliz@gnu.org, 48118@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Excuse me if I'm mistaken, but doesn't pselect return all file descriptors that are ready for reading? Couldn't we then simply process all of them (in a for loop) after pselect returns? From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 30 12:18:00 2021 Received: (at 48118) by debbugs.gnu.org; 30 Apr 2021 16:18:00 +0000 Received: from localhost ([127.0.0.1]:59699 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcVq4-0001NI-5S for submit@debbugs.gnu.org; Fri, 30 Apr 2021 12:18:00 -0400 Received: from server.qxqx.de ([178.63.65.180]:60019 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcVq2-0001N3-4t for 48118@debbugs.gnu.org; Fri, 30 Apr 2021 12:17:58 -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=BsGnEcKcdaN2xAZepPtfvABAJL0pvmjEU9hq49zvY5o=; b=XIBWkH0NADrVJA+ZnnK0LRn+jj e/Mb4/v1TBPx2YY5CM2uJhPbE2gVs3ipBh/3sgx086uMsD3qKPk01AjVcaaqfuO4lgWQXww8Jk7aS 5Aqk3AyjdiFd0RY33FfPB1irmAzu30n3PxvT0uDaSc+Y1EePB/3ND1xMnydVg4Xy/Xl0=; Subject: Re: bug#48118: 27.1; 28; Only first process receives output with multiple running processes To: Eli Zaretskii 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> <83bl9vbw8h.fsf@gnu.org> From: Daniel Mendler Message-ID: <70ea83e2-fc9e-6feb-240c-ed41abac5254@daniel-mendler.de> Date: Fri, 30 Apr 2021 18:17:49 +0200 MIME-Version: 1.0 In-Reply-To: <83bl9vbw8h.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 48118 Cc: 48118@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 4/30/21 5:58 PM, Eli Zaretskii wrote: > A call to accept-process-output prioritizes a process only if it > explicitly requests output from that single process. Which is not > necessarily true in all cases. Yes, I have seen that in the documentation. >>> 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?). > > Bytes read has a problem when processes produce output a very > different rates. Time spent to handle may (and usually does) mean the > filter function does something expensive, it doesn't necessarily tell > anything about the output from the subprocess. Of course it is not possible to find a perfect scheduling algorithm. But how does the OS handle it if you have multiple processes which produce output with vastly different rates? I am not claiming this problem has been solved, but there are certainly some heuristics. Emacs is also dependent on the OS scheduling, depending on how Emacs schedules its reads/writes from the processes, the OS scheduler adjusts accordingly. This furthermore complicates the picture. >> 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. > > If you read the code, you will see this isn't what happens. What > happens is that Emacs reads a chunk of output from the first process > it sees ready, then it goes back and re-checks which processes are > ready -- and in your scenario I think it again sees that the first > process is ready. This is what we assumed. Emacs could check the second process the next time. This way one may get a slightly more fair behavior. It would certainly not be perfect and you could throw scenarios at it which would make it behave unexpectedly. It may behave a bit more expectedly in the common case? > I suggest to read the code of wait_reading_process_output, it has some > non-trivial logic in this department. I will do that. Has this problem discussed before? From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 30 13:52:42 2021 Received: (at 48118) by debbugs.gnu.org; 30 Apr 2021 17:52:42 +0000 Received: from localhost ([127.0.0.1]:59779 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcXJi-00064t-2u for submit@debbugs.gnu.org; Fri, 30 Apr 2021 13:52:42 -0400 Received: from eggs.gnu.org ([209.51.188.92]:39744) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcXJg-00064h-MX for 48118@debbugs.gnu.org; Fri, 30 Apr 2021 13:52:41 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:53143) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lcXJb-0005n5-2A; Fri, 30 Apr 2021 13:52:35 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1823 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lcXJa-0004TJ-9J; Fri, 30 Apr 2021 13:52:34 -0400 Date: Fri, 30 Apr 2021 20:52:29 +0300 Message-Id: <837dkjbqxu.fsf@gnu.org> From: Eli Zaretskii To: jakanakaevangeli@chiru.no In-Reply-To: <87pmyb6963.fsf@miha-pc> (jakanakaevangeli@chiru.no) Subject: Re: bug#48118: 27.1; 28; Only first process receives output with multiple running processes References: <87pmyb6963.fsf@miha-pc> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 48118 Cc: mail@daniel-mendler.de, 48118@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: jakanakaevangeli@chiru.no > Cc: eliz@gnu.org, 48118@debbugs.gnu.org > Date: Fri, 30 Apr 2021 18:15:16 +0200 > > Excuse me if I'm mistaken, but doesn't pselect return all file > descriptors that are ready for reading? Couldn't we then simply process > all of them (in a for loop) after pselect returns? That's what we do, but with a twist that I described. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 30 14:06:41 2021 Received: (at 48118) by debbugs.gnu.org; 30 Apr 2021 18:06:41 +0000 Received: from localhost ([127.0.0.1]:59813 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcXXF-0006TO-E3 for submit@debbugs.gnu.org; Fri, 30 Apr 2021 14:06:41 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42620) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcXXE-0006TD-F6 for 48118@debbugs.gnu.org; Fri, 30 Apr 2021 14:06:40 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:53643) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lcXX8-0003dr-BC; Fri, 30 Apr 2021 14:06:34 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2678 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lcXX4-000491-Rx; Fri, 30 Apr 2021 14:06:32 -0400 Date: Fri, 30 Apr 2021 21:06:22 +0300 Message-Id: <83y2czabq9.fsf@gnu.org> From: Eli Zaretskii To: Daniel Mendler In-Reply-To: <70ea83e2-fc9e-6feb-240c-ed41abac5254@daniel-mendler.de> (message from Daniel Mendler on Fri, 30 Apr 2021 18:17:49 +0200) Subject: Re: bug#48118: 27.1; 28; Only first process receives output with multiple running processes 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> <83bl9vbw8h.fsf@gnu.org> <70ea83e2-fc9e-6feb-240c-ed41abac5254@daniel-mendler.de> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 48118 Cc: 48118@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 48118@debbugs.gnu.org > From: Daniel Mendler > Date: Fri, 30 Apr 2021 18:17:49 +0200 > > > Bytes read has a problem when processes produce output a very > > different rates. Time spent to handle may (and usually does) mean the > > filter function does something expensive, it doesn't necessarily tell > > anything about the output from the subprocess. > > Of course it is not possible to find a perfect scheduling algorithm. But > how does the OS handle it if you have multiple processes which produce > output with vastly different rates? I am not claiming this problem has > been solved, but there are certainly some heuristics. Emacs is also > dependent on the OS scheduling, depending on how Emacs schedules its > reads/writes from the processes, the OS scheduler adjusts accordingly. > This furthermore complicates the picture. I'm sure patches to tune the scheduling to specific use cases will be welcome. My gut feeling is that we will need some variables to allow Lisp programs to tell Emacs how to handle the various kinds of processes and combinations thereof, but if you can come up with patches that automatically adapt to the process's behavior, that would be even better. You could also try playing with the value of read-process-output-max, perhaps enlarging it will make the problem in your case less severe. > > If you read the code, you will see this isn't what happens. What > > happens is that Emacs reads a chunk of output from the first process > > it sees ready, then it goes back and re-checks which processes are > > ready -- and in your scenario I think it again sees that the first > > process is ready. > > This is what we assumed. Emacs could check the second process the next > time. This way one may get a slightly more fair behavior. It would > certainly not be perfect and you could throw scenarios at it which would > make it behave unexpectedly. It may behave a bit more expectedly in the > common case? We could try that (conditioned on some new variable) and see if this has downsides. > > I suggest to read the code of wait_reading_process_output, it has some > > non-trivial logic in this department. > > I will do that. Has this problem discussed before? I don't think so, but my memory is not to be trusted. From debbugs-submit-bounces@debbugs.gnu.org Sun May 02 03:23:44 2021 Received: (at 48118) by debbugs.gnu.org; 2 May 2021 07:23:44 +0000 Received: from localhost ([127.0.0.1]:41112 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ld6S8-0007Ol-9E for submit@debbugs.gnu.org; Sun, 02 May 2021 03:23:44 -0400 Received: from quimby.gnus.org ([95.216.78.240]:55036) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ld6S6-0007Ob-3p for 48118@debbugs.gnu.org; Sun, 02 May 2021 03:23:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: 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=jX6yH6WHPoLM9d/mzt5U6qHOSr13utPdg7IYl2gBY3U=; b=CXzGApIRnaSK03KFdjcgHmpmzX Ht1Baj7kB69j+nImj3WCOJQMzvv9XI85C7HI05n5bF3YTUgJn5NHmj/uoqsvlUjD5yqN9pMQKhAQx /olEYC0ITs9ENuTKjpwruIiGLaO7Sl26034c1+mfcCk9smfk1/gg9MeImMZ/AhCQ6yXU=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ld6Rx-0003mH-Vd; Sun, 02 May 2021 09:23:36 +0200 From: Lars Ingebrigtsen To: Daniel Mendler Subject: Re: bug#48118: 27.1; 28; Only first process receives output with multiple running processes 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> <83bl9vbw8h.fsf@gnu.org> <70ea83e2-fc9e-6feb-240c-ed41abac5254@daniel-mendler.de> X-Now-Playing: Zola Jesus's _New Amsterdam_: "Odessa" Date: Sun, 02 May 2021 09:23:33 +0200 In-Reply-To: <70ea83e2-fc9e-6feb-240c-ed41abac5254@daniel-mendler.de> (Daniel Mendler's message of "Fri, 30 Apr 2021 18:17:49 +0200") Message-ID: <87v981k39m.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Daniel Mendler writes: > This is what we assumed. Emacs could check the second process the next > time. This way one may get a slightly more fair behavior. Yes, more fairness in how Emacs handles process output would be nice, indeed. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 48118 Cc: Eli Zaretskii , 48118@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Daniel Mendler writes: > This is what we assumed. Emacs could check the second process the next > time. This way one may get a slightly more fair behavior. Yes, more fairness in how Emacs handles process output would be nice, indeed. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Mon May 24 17:00:31 2021 Received: (at 48118) by debbugs.gnu.org; 24 May 2021 21:00:31 +0000 Received: from localhost ([127.0.0.1]:44015 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1llHgd-0000Fl-4A for submit@debbugs.gnu.org; Mon, 24 May 2021 17:00:31 -0400 Received: from kamnitnik.top ([209.250.245.214]:59044 helo=mail.kamnitnik.top) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1llHga-0000Fc-6C for 48118@debbugs.gnu.org; Mon, 24 May 2021 17:00:29 -0400 Received: from localhost (unknown [IPv6:2a00:ee2:e04:9300:b7eb:7ae7:cc56:e0da]) by mail.kamnitnik.top (Postfix) with ESMTPSA id 88E57BBB78; Mon, 24 May 2021 21:00:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kamnitnik.top; s=mail; t=1621890026; bh=Dwhcu+X94gIPJ+1rlfe3KONcsRp8lwDkiURU+b44QW4=; h=From:To:Cc:Subject:In-Reply-To:Date:From; b=VsB4F3oLNhnu1D2CJBVGWKCGzkk9ezprh9og3UE/mW/Nk1TMilVoNfi4OU7s00HuF ItZKGS9nrtrY7CSBgzQjdLJRbnm/mJulWxV/lLWa+bRsn6jiYay+m4/g+SyEywZeI/ NItwVKnKlZcX2HOeLAU2p11ZVh4M3KnwHQ9V/K47A5Phox28L3SfuDwedgef9vLawi 3ph8B8Wwy+Md9ORX7b1rmbrX/BMhdo//WKMq62xg1WwA7UxdfaQU1Vy8WXGxP4kyb8 fb2P4JCspOWyptIsabRaDwgNrRz5a4SCzr8tTe8UcU6fwCBRx7z/podgkmhp0EIMG0 pThNM8tShAb8w== From: miha@kamnitnik.top To: Lars Ingebrigtsen Subject: Re: bug#48118: 27.1; 28; Only first process receives output with multiple running processes In-Reply-To: <87v981k39m.fsf@gnus.org> (message from Lars Ingebrigtsen on Sun, 02 May 2021 09:23:33 +0200) Date: Mon, 24 May 2021 23:05:47 +0200 Message-ID: <86bl8z7sgk.fsf@miha-pc> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Spam-Score: 2.5 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: I propose the following simple patch. It makes output from multiple /bin/yes programs arrive at the same rate and multiple grep processes can run without them seemingly blocking each other. From 29544585ec07ec180bb13fac9142d3755c597cd9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Miha=20Rihtar=C5=A1i=C4=8D?= Date: Mon, 24 May 2021 22:46:47 +0200 Subject: [PATCH] Try to n [...] Content analysis details: (2.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: kamnitnik.top (top)] 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD X-Debbugs-Envelope-To: 48118 Cc: mail@daniel-mendler.de, eliz@gnu.org, 48118@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.5 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: I propose the following simple patch. It makes output from multiple /bin/yes programs arrive at the same rate and multiple grep processes can run without them seemingly blocking each other. From 29544585ec07ec180bb13fac9142d3755c597cd9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Miha=20Rihtar=C5=A1i=C4=8D?= Date: Mon, 24 May 2021 22:46:47 +0200 Subject: [PATCH] Try to n [...] Content analysis details: (2.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: kamnitnik.top (top)] 1.0 BULK_RE_SUSP_NTLD Precedence bulk and RE: from a suspicious TLD 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain I propose the following simple patch. It makes output from multiple /bin/yes programs arrive at the same rate and multiple grep processes can run without them seemingly blocking each other. --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Try-to-not-prioritise-reading-from-lower-fds.patch Content-Transfer-Encoding: quoted-printable From=2029544585ec07ec180bb13fac9142d3755c597cd9 Mon Sep 17 00:00:00 2001 From: =3D?UTF-8?q?Miha=3D20Rihtar=3DC5=3DA1i=3DC4=3D8D?=3D Date: Mon, 24 May 2021 22:46:47 +0200 Subject: [PATCH] Try to not prioritise reading from lower fds * src/process.c (wait_reading_process_output): When looping through fds, continue from where we left off. =2D-- src/process.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/src/process.c b/src/process.c index 47a2a6f1a3..9c2f328ebc 100644 =2D-- a/src/process.c +++ b/src/process.c @@ -5134,6 +5134,7 @@ wait_reading_process_output (intmax_t time_limit, int= nsecs, int read_kbd, Lisp_Object wait_for_cell, struct Lisp_Process *wait_proc, int just_wait_proc) { + static int last_read_channel =3D -1; int channel, nfds; fd_set Available; fd_set Writeok; @@ -5188,6 +5189,7 @@ wait_reading_process_output (intmax_t time_limit, int= nsecs, int read_kbd, while (1) { bool process_skipped =3D false; + bool wrapped; =20 /* If calling from keyboard input, do not quit since we want to return C-g as an input character. @@ -5722,8 +5724,17 @@ wait_reading_process_output (intmax_t time_limit, in= t nsecs, int read_kbd, d->func (channel, d->data); } =20 =2D for (channel =3D 0; channel <=3D max_desc; channel++) =2D { + for (channel =3D last_read_channel + 1, wrapped =3D false; + !wrapped || (channel <=3D last_read_channel && channel <=3D max_desc); + channel++) + { + if (channel > max_desc) + { + wrapped =3D true; + channel =3D -1; + continue; + } + if (FD_ISSET (channel, &Available) && ((fd_callback_info[channel].flags & (KEYBOARD_FD | PROCESS_FD)) =3D=3D PROCESS_FD)) @@ -5761,6 +5772,7 @@ wait_reading_process_output (intmax_t time_limit, int= nsecs, int read_kbd, don't try to read from any other processes before doing the select again. */ FD_ZERO (&Available); + last_read_channel =3D channel; =20 if (do_display) redisplay_preserve_echo_area (12); =2D-=20 2.31.1 --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJHBAEBCAAxFiEEmxVnesoT5rQXvVXnswkaGpIVmT8FAmCsFSsTHG1paGFAa2Ft bml0bmlrLnRvcAAKCRCzCRoakhWZPxEMEAClRWlM+qdc9krvYul/FhbOa9mKs7ec BsT6MoaV3hA5gAct3IZ+dGbPP8xX6stHTYsoi0DH7TOVbMxKBQK/95C6NYv+d/1E Xocx50O7pmcSUilT+zXvE1JspTpTqGYmfI/+SzSTt9GlAiMBcuEa9dj7qm8Ve44n Lc/DjR12IsioTuBOo7pyLcx/P4QSQjfMyaNkQRgmaXY5o0ofpR30Zlo8JzXty7As nw6rw8MOUvJ1odxPxSCI6NvUy/FKYti9cBYMVoO8Z7GWmbDrsBOrSZ7w8lgELbYg lZdHFD9l2KP7ENAqCW8NiTF8vqn6vXVmkfT+BYwTKPFTosJBd27tVQ3dxIY68snj cR16d8wonlTcmlEzJrrA407ppWMWYc8VWJ+jblQ9xD3F+rBR8LjM2Mu10uwJ91Ej UIS4Kj8Bkv/sdJDH0TZWBrXPn6YcnV2jfPEFe4G5wFOLq9IqOyadfR6eR9bChZTb cvVjus5bKMz+ZU11pr9R3B2ow+vkJ1gWO3+SDjOUaHo39doWcgz2/KAuSgGqD9Je 1m2zbgBaI1lEzQlVUIw2GHjLcXDJJrSOQsevALKuSOvg5K3GRwYNczvhUQEkeCUd k05xC/MBLTOcBwScaMm3tuYr7dxhUG5utiCIt4zp8USeJcpxJYuK6xJZWoR+Zmio LLU7hPnwioM/jA== =IpBR -----END PGP SIGNATURE----- --==-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue May 25 07:38:31 2021 Received: (at 48118) by debbugs.gnu.org; 25 May 2021 11:38:31 +0000 Received: from localhost ([127.0.0.1]:44858 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1llVOJ-0001QP-Hk for submit@debbugs.gnu.org; Tue, 25 May 2021 07:38:31 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40494) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1llVOF-0001Q9-U8 for 48118@debbugs.gnu.org; Tue, 25 May 2021 07:38:29 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41990) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1llVO8-0003Ak-Hl; Tue, 25 May 2021 07:38:20 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1396 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 1llVO8-0004y2-3J; Tue, 25 May 2021 07:38:20 -0400 Date: Tue, 25 May 2021 14:38:17 +0300 Message-Id: <83im37cac6.fsf@gnu.org> From: Eli Zaretskii To: miha@kamnitnik.top In-Reply-To: <86bl8z7sgk.fsf@miha-pc> Subject: Re: bug#48118: 27.1; 28; Only first process receives output with multiple running processes References: <86bl8z7sgk.fsf@miha-pc> X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: 48118 Cc: mail@daniel-mendler.de, larsi@gnus.org, 48118@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > From: miha@kamnitnik.top > Cc: mail@daniel-mendler.de, eliz@gnu.org, 48118@debbugs.gnu.org > Date: Mon, 24 May 2021 23:05:47 +0200 > > I propose the following simple patch. It makes output from multiple > /bin/yes programs arrive at the same rate and multiple grep processes > can run without them seemingly blocking each other. Thanks, but I don't think we can make such changes unconditionally. I'm okay with trying this by default, but we should have a Lisp variable that would allow to get back to the old behavior. That's because if some user complains about some problems, and we think the problems are caused by this change, we could tell that user to flip the variable and see if the problems go away. That variable should also be in NEWS. From debbugs-submit-bounces@debbugs.gnu.org Tue May 25 11:13:15 2021 Received: (at 48118) by debbugs.gnu.org; 25 May 2021 15:13:15 +0000 Received: from localhost ([127.0.0.1]:46561 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1llYjy-00019H-Gw for submit@debbugs.gnu.org; Tue, 25 May 2021 11:13:15 -0400 Received: from kamnitnik.top ([209.250.245.214]:34050 helo=mail.kamnitnik.top) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1llYjt-00018p-SM for 48118@debbugs.gnu.org; Tue, 25 May 2021 11:13:04 -0400 Received: from localhost (unknown [IPv6:2a00:ee2:e04:9300:b7eb:7ae7:cc56:e0da]) by mail.kamnitnik.top (Postfix) with ESMTPSA id C742FBBB83; Tue, 25 May 2021 15:12:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kamnitnik.top; s=mail; t=1621955579; bh=peVTDNVmfaOPe5JBpKEknFj+BIjBx4AraA07k+nS+1A=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=UVuHFVQ4ks/NJwWpp9Hc1ekMqe03JoYr5GYRnJEgykPTQHeENyIWT/MrhKvvMEy1a d66njW5G0eRv1vh1Fa7XUQ19z6pxZDuGnOION2yg91RP9yGq3Pig7xYY2idVzN4I7A 4tJx468/NMFJCzguLixNp+kW/LwwneH61lbnRRwwO1cVB2oC3zQxfU1S1cvMUdsAv5 66HZaYkuou1MTAQ5V9tVqrNtWP5b1lbmW0NkhI6pyZCQim+/E84XiJxqcXY76rmXC4 Khv3SGT/QioSsJRdzENlmxdHvJF01LW7Qt9zEmvJCtGhGQ0fRS51+Hn25dpg8/vwsC DuFtaoWwH/7KA== From: To: Eli Zaretskii Subject: Re: bug#48118: 27.1; 28; Only first process receives output with multiple running processes In-Reply-To: <83im37cac6.fsf@gnu.org> References: <86bl8z7sgk.fsf@miha-pc> <83im37cac6.fsf@gnu.org> Date: Tue, 25 May 2021 17:18:22 +0200 Message-ID: <868s427sg1.fsf@miha-pc> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Spam-Score: 2.5 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: >> From: miha@kamnitnik.top >> Cc: mail@daniel-mendler.de, eliz@gnu.org, 48118@debbugs.gnu.org >> Date: Mon, 24 May 2021 23:05:47 +0200 >> >> I propose the following simple patch. It makes output from [...] Content analysis details: (2.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: kamnitnik.top (top)] 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD X-Debbugs-Envelope-To: 48118 Cc: mail@daniel-mendler.de, larsi@gnus.org, 48118@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.5 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: >> From: miha@kamnitnik.top >> Cc: mail@daniel-mendler.de, eliz@gnu.org, 48118@debbugs.gnu.org >> Date: Mon, 24 May 2021 23:05:47 +0200 >> >> I propose the following simple patch. It makes output from [...] Content analysis details: (2.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 T_SPF_TEMPERROR SPF: test of record failed (temperror) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: kamnitnik.top (top)] 1.0 BULK_RE_SUSP_NTLD Precedence bulk and RE: from a suspicious TLD 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Eli Zaretskii writes: >> From: miha@kamnitnik.top >> Cc: mail@daniel-mendler.de, eliz@gnu.org, 48118@debbugs.gnu.org >> Date: Mon, 24 May 2021 23:05:47 +0200 >>=20 >> I propose the following simple patch. It makes output from multiple >> /bin/yes programs arrive at the same rate and multiple grep processes >> can run without them seemingly blocking each other. > > Thanks, but I don't think we can make such changes unconditionally. > I'm okay with trying this by default, but we should have a Lisp > variable that would allow to get back to the old behavior. That's > because if some user complains about some problems, and we think the > problems are caused by this change, we could tell that user to flip > the variable and see if the problems go away. > > That variable should also be in NEWS. Revised patch. --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Try-to-not-prioritise-reading-from-lower-fds.patch Content-Transfer-Encoding: quoted-printable From=2077fb8097f2ed20f034230a5c61dee00880bbcd24 Mon Sep 17 00:00:00 2001 From: =3D?UTF-8?q?Miha=3D20Rihtar=3DC5=3DA1i=3DC4=3D8D?=3D Date: Mon, 24 May 2021 22:46:47 +0200 Subject: [PATCH] Try to not prioritise reading from lower fds * src/process.c (wait_reading_process_output): When looping through fds, continue from where we left off. (syms_of_process): Vprocess_prioritize_lower_fds: New variable =2D-- etc/NEWS | 7 +++++++ src/process.c | 27 +++++++++++++++++++++++++-- 2 files changed, 32 insertions(+), 2 deletions(-) diff --git a/etc/NEWS b/etc/NEWS index 1541b74a3b..cc767c8dc2 100644 =2D-- a/etc/NEWS +++ b/etc/NEWS @@ -2706,6 +2706,13 @@ the Emacs Lisp reference manual for background. * Lisp Changes in Emacs 28.1 =20 +++ +** New variable 'process-prioritize-lower-fds' +When looping through file descriptors to handle subprocess output, try +to continue from where the previous loop left off instead of always +beginning from file descriptor zero. Set this variable to t to get +the old behaviour. + +--- ** New function 'sxhash-equal-including-properties'. This is identical to 'sxhash-equal' but accounting also for string properties. diff --git a/src/process.c b/src/process.c index 47a2a6f1a3..7bf55c203e 100644 =2D-- a/src/process.c +++ b/src/process.c @@ -5134,6 +5134,7 @@ wait_reading_process_output (intmax_t time_limit, int= nsecs, int read_kbd, Lisp_Object wait_for_cell, struct Lisp_Process *wait_proc, int just_wait_proc) { + static int last_read_channel =3D -1; int channel, nfds; fd_set Available; fd_set Writeok; @@ -5188,6 +5189,8 @@ wait_reading_process_output (intmax_t time_limit, int= nsecs, int read_kbd, while (1) { bool process_skipped =3D false; + bool wrapped; + int channel_start; =20 /* If calling from keyboard input, do not quit since we want to return C-g as an input character. @@ -5722,8 +5725,20 @@ wait_reading_process_output (intmax_t time_limit, in= t nsecs, int read_kbd, d->func (channel, d->data); } =20 =2D for (channel =3D 0; channel <=3D max_desc; channel++) =2D { + channel_start + =3D !NILP (Vprocess_prioritize_lower_fds) ? 0 : last_read_channel + 1; + + for (channel =3D channel_start, wrapped =3D false; + !wrapped || (channel < channel_start && channel <=3D max_desc); + channel++) + { + if (channel > max_desc) + { + wrapped =3D true; + channel =3D -1; + continue; + } + if (FD_ISSET (channel, &Available) && ((fd_callback_info[channel].flags & (KEYBOARD_FD | PROCESS_FD)) =3D=3D PROCESS_FD)) @@ -5761,6 +5776,7 @@ wait_reading_process_output (intmax_t time_limit, int= nsecs, int read_kbd, don't try to read from any other processes before doing the select again. */ FD_ZERO (&Available); + last_read_channel =3D channel; =20 if (do_display) redisplay_preserve_echo_area (12); @@ -8477,6 +8493,13 @@ syms_of_process (void) The variable takes effect when `start-process' is called. */); Vprocess_adaptive_read_buffering =3D Qt; =20 + DEFVAR_LISP ("process-prioritize-lower-fds", Vprocess_prioritize_lower_f= ds, + doc: /* If nil, try to not prioritize reading from any process. +Emacs loops through file descriptors to receive data from subprocesses. A= fter +accepting output from the first file descriptor with available data, resta= rt the +loop from the file descriptor 0 if this option is non-nil. */); + Vprocess_prioritize_lower_fds =3D Qnil; + DEFVAR_LISP ("interrupt-process-functions", Vinterrupt_process_functions, doc: /* List of functions to be called for `interrupt-process'. The arguments of the functions are the same as for `interrupt-process'. =2D-=20 2.31.1 --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJHBAEBCAAxFiEEmxVnesoT5rQXvVXnswkaGpIVmT8FAmCtFT4THG1paGFAa2Ft bml0bmlrLnRvcAAKCRCzCRoakhWZP+wPEAC2xizoCIuatCksnIEjEp5NP6BT5wbY Sl6TIo8Qs8qAjpFuHlxOZMlgFpIWUQcOzZy3cF7VZ5WhaM5XQTAAQ416IQUmWNAQ QlZ6HxVDIBWL/IoR8oLP9TVSrTX2mWvUxXBXX2u3tuqfbRLx5lOPWHRMkkpd3jLU NiIPYw5xxB44xeOO57jdz+od3iffnIOwv869VH+9B2svL1AfLjRHWLbxV3jLYae1 34DVhANQ9XN3RTf8SkxcXmGiFSwPz4hjPuCRXXV7Vk3RFNAlCB2CvIKyClQspFEQ /qj1MDiJzdshnf5Sp84OjNzBbKvePIdCiyaQUkPjSgUA6D4T03oHjiKKIIwK3iv5 VmwyPALqcGAAlpXe4OmmYQ4VSlyFTLyFBAAc63IpgNvMmgoms3+sdTGe3N+Z75/N f0ieQbxpNnNKhYz21cT7DDl5nvywejnNI62qVHjd7XO9meRVjQOYwhxr5GexslUC po/qQh9RSXhhNZc4+qSSUorR/5yI+gVkMk2xdG5Ieu36mk9dUqkxDnbZL6628mcb tjT9Lp0hBZOPquOj4pDjYZ54uEfQgYwK7ZuUy9gtwktP5nvuR1XlwyjMPkPD22Se W/s+3wyo5Ei7ENwoloBmBkDMkI3s+QEyNisJ0DT07n04t5/0qAr7tXcwe1Wyomqb GeVciukGotwETw== =eL8Q -----END PGP SIGNATURE----- --==-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue May 25 13:12:48 2021 Received: (at 48118) by debbugs.gnu.org; 25 May 2021 17:12:48 +0000 Received: from localhost ([127.0.0.1]:46644 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1llabo-0004He-4h for submit@debbugs.gnu.org; Tue, 25 May 2021 13:12:48 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38278) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1llabk-0004HO-Oi for 48118@debbugs.gnu.org; Tue, 25 May 2021 13:12:46 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55808) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1llabc-0006lV-K8; Tue, 25 May 2021 13:12:36 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2301 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 1llabY-0000ea-IQ; Tue, 25 May 2021 13:12:35 -0400 Date: Tue, 25 May 2021 20:12:28 +0300 Message-Id: <83pmxebuv7.fsf@gnu.org> From: Eli Zaretskii To: miha@kamnitnik.top In-Reply-To: <868s427sg1.fsf@miha-pc> Subject: Re: bug#48118: 27.1; 28; Only first process receives output with multiple running processes References: <86bl8z7sgk.fsf@miha-pc> <83im37cac6.fsf@gnu.org> <868s427sg1.fsf@miha-pc> X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: 48118 Cc: mail@daniel-mendler.de, larsi@gnus.org, 48118@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > From: > Cc: larsi@gnus.org, mail@daniel-mendler.de, 48118@debbugs.gnu.org > Date: Tue, 25 May 2021 17:18:22 +0200 > > Revised patch. Thanks. > --- a/etc/NEWS > +++ b/etc/NEWS > @@ -2706,6 +2706,13 @@ the Emacs Lisp reference manual for background. > * Lisp Changes in Emacs 28.1 > > +++ > +** New variable 'process-prioritize-lower-fds' > +When looping through file descriptors to handle subprocess output, try > +to continue from where the previous loop left off instead of always > +beginning from file descriptor zero. Set this variable to t to get > +the old behaviour. > + > +--- The "+++" and "---" markers should be reversed. > + DEFVAR_LISP ("process-prioritize-lower-fds", Vprocess_prioritize_lower_fds, > + doc: /* If nil, try to not prioritize reading from any process. > +Emacs loops through file descriptors to receive data from subprocesses. After > +accepting output from the first file descriptor with available data, restart the > +loop from the file descriptor 0 if this option is non-nil. */); > + Vprocess_prioritize_lower_fds = Qnil; Please use DEVAR_BOOL, since this is a boolean variable. From debbugs-submit-bounces@debbugs.gnu.org Tue May 25 13:57:39 2021 Received: (at 48118) by debbugs.gnu.org; 25 May 2021 17:57:39 +0000 Received: from localhost ([127.0.0.1]:46705 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1llbJC-0005OY-Uj for submit@debbugs.gnu.org; Tue, 25 May 2021 13:57:39 -0400 Received: from kamnitnik.top ([209.250.245.214]:34416 helo=mail.kamnitnik.top) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1llbJA-0005OP-OC for 48118@debbugs.gnu.org; Tue, 25 May 2021 13:57:38 -0400 Received: from localhost (unknown [IPv6:2a00:ee2:e04:9300:b7eb:7ae7:cc56:e0da]) by mail.kamnitnik.top (Postfix) with ESMTPSA id 315ABBBB83; Tue, 25 May 2021 17:57:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kamnitnik.top; s=mail; t=1621965455; bh=4hRZWDzf+K2/VmMs9F4XnC6YMWFT5MzHIKmbNsOgafM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=mj/44UZHcQlvGK1fZ8s86z6pF1QhMOrcnbfNB/9bjWWfdC4mK8Ne3LLYEgNZLncWK us7hoxhBMZLbbxQzY8MWE8YFgaJYP+O7/t2auQ9tgeCASQHvqzIzzLKyfOBcgb87vp 8E4oB9tK+c7JUzfNZoGs8pal0BJ5ucQ1hwCOE9QnyY98UH7FuvnYMVqZmNas5Etj4W /yNudmAj3xkcJt4iSLjickmcHWvAFbKKI9sv3GtYjF9heexK71gtKfqmeOQnDvMNTW UjGc4n7Aay2btPxlOgqoyYIp4oanLlsG1LV6FSkrTiIanOFwxj8Zy8N60yFh4IndVV yCogdl8sFbjwA== From: To: Eli Zaretskii Subject: Re: bug#48118: 27.1; 28; Only first process receives output with multiple running processes In-Reply-To: <83pmxebuv7.fsf@gnu.org> References: <86bl8z7sgk.fsf@miha-pc> <83im37cac6.fsf@gnu.org> <868s427sg1.fsf@miha-pc> <83pmxebuv7.fsf@gnu.org> Date: Tue, 25 May 2021 20:02:57 +0200 Message-ID: <86tumq4rou.fsf@miha-pc> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Spam-Score: 2.5 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: > The "+++" and "---" markers should be reversed. Whoops. Content analysis details: (2.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: kamnitnik.top (top)] 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD X-Debbugs-Envelope-To: 48118 Cc: mail@daniel-mendler.de, larsi@gnus.org, 48118@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.5 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: > The "+++" and "---" markers should be reversed. Whoops. Content analysis details: (2.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: kamnitnik.top (top)] 1.0 BULK_RE_SUSP_NTLD Precedence bulk and RE: from a suspicious TLD 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain Eli Zaretskii writes: > The "+++" and "---" markers should be reversed. Whoops. >> + DEFVAR_LISP ("process-prioritize-lower-fds", Vprocess_prioritize_lower_fds, >> + doc: /* If nil, try to not prioritize reading from any process. >> +Emacs loops through file descriptors to receive data from subprocesses. After >> +accepting output from the first file descriptor with available data, restart the >> +loop from the file descriptor 0 if this option is non-nil. */); >> + Vprocess_prioritize_lower_fds = Qnil; > > Please use DEVAR_BOOL, since this is a boolean variable. Tanks for feedback, posting revised patch. --=-=-= Content-Type: #("text/x-patch" 0 12 (fontified nil)) Content-Disposition: inline; filename=0001-Try-to-not-prioritise-reading-from-lower-fds.patch Content-Transfer-Encoding: quoted-printable From=20d2cc936a1ce2c536abcb285ecf556988c8f4b4ec Mon Sep 17 00:00:00 2001 From: =3D?UTF-8?q?Miha=3D20Rihtar=3DC5=3DA1i=3DC4=3D8D?=3D Date: Mon, 24 May 2021 22:46:47 +0200 Subject: [PATCH] Try to not prioritise reading from lower fds * src/process.c (wait_reading_process_output): When looping through fds, continue from where we left off. (syms_of_process): Vprocess_prioritize_lower_fds: New variable =2D-- etc/NEWS | 7 +++++++ src/process.c | 25 ++++++++++++++++++++++++- 2 files changed, 31 insertions(+), 1 deletion(-) diff --git a/etc/NEWS b/etc/NEWS index 1541b74a3b..5bce2c7c88 100644 =2D-- a/etc/NEWS +++ b/etc/NEWS @@ -2705,6 +2705,13 @@ the Emacs Lisp reference manual for background. * Lisp Changes in Emacs 28.1 =20 +--- +** New variable 'process-prioritize-lower-fds' +When looping through file descriptors to handle subprocess output, try +to continue from where the previous loop left off instead of always +beginning from file descriptor zero. Set this variable to t to get +the old behaviour. + +++ ** New function 'sxhash-equal-including-properties'. This is identical to 'sxhash-equal' but accounting also for string diff --git a/src/process.c b/src/process.c index 47a2a6f1a3..ca19242afb 100644 =2D-- a/src/process.c +++ b/src/process.c @@ -5134,6 +5134,7 @@ wait_reading_process_output (intmax_t time_limit, int= nsecs, int read_kbd, Lisp_Object wait_for_cell, struct Lisp_Process *wait_proc, int just_wait_proc) { + static int last_read_channel =3D -1; int channel, nfds; fd_set Available; fd_set Writeok; @@ -5188,6 +5189,8 @@ wait_reading_process_output (intmax_t time_limit, int= nsecs, int read_kbd, while (1) { bool process_skipped =3D false; + bool wrapped; + int channel_start; =20 /* If calling from keyboard input, do not quit since we want to return C-g as an input character. @@ -5722,8 +5725,20 @@ wait_reading_process_output (intmax_t time_limit, in= t nsecs, int read_kbd, d->func (channel, d->data); } =20 =2D for (channel =3D 0; channel <=3D max_desc; channel++) + channel_start + =3D process_prioritize_lower_fds ? 0 : last_read_channel + 1; + + for (channel =3D channel_start, wrapped =3D false; + !wrapped || (channel < channel_start && channel <=3D max_desc); + channel++) { + if (channel > max_desc) + { + wrapped =3D true; + channel =3D -1; + continue; + } + if (FD_ISSET (channel, &Available) && ((fd_callback_info[channel].flags & (KEYBOARD_FD | PROCESS_FD)) =3D=3D PROCESS_FD)) @@ -5761,6 +5776,7 @@ wait_reading_process_output (intmax_t time_limit, int= nsecs, int read_kbd, don't try to read from any other processes before doing the select again. */ FD_ZERO (&Available); + last_read_channel =3D channel; =20 if (do_display) redisplay_preserve_echo_area (12); @@ -8477,6 +8493,13 @@ syms_of_process (void) The variable takes effect when `start-process' is called. */); Vprocess_adaptive_read_buffering =3D Qt; =20 + DEFVAR_BOOL ("process-prioritize-lower-fds", process_prioritize_lower_fd= s, + doc: /* If nil, try to not prioritize reading from any process. +Emacs loops through file descriptors to receive data from subprocesses. A= fter +accepting output from the first file descriptor with available data, resta= rt the +loop from the file descriptor 0 if this option is non-nil. */); + process_prioritize_lower_fds =3D 0; + DEFVAR_LISP ("interrupt-process-functions", Vinterrupt_process_functions, doc: /* List of functions to be called for `interrupt-process'. The arguments of the functions are the same as for `interrupt-process'. =2D-=20 2.31.1 --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJHBAEBCAAxFiEEmxVnesoT5rQXvVXnswkaGpIVmT8FAmCtO9ETHG1paGFAa2Ft bml0bmlrLnRvcAAKCRCzCRoakhWZP8rxEAC+qT4g41i5/WvbAePpwrjxsIO2VTbh pIp1GOAoI/05BOprwBjxzvkgq66Xp1c9DAkEXxps86jU8UTUL+YYzWOhVmfUk9sG nUtXbGnfb5MKSe/ztYQDWtLdgmo4xm8yI4djYbhWIKjAKcp93bqQZuILdoqp1fjK yot1/nlnybPQkyXQFpcaMojsfL1e4U86C59PGdhU0LqnWn7K2KJE0V3PalOJnYm/ CPYgZVJUKJIy8TBgSkLj+6VrWrddSRx9Em0lJAkswE1lEKEfqN3cwgmS6i5/oBTO wiw9Vvy00jSPZzG4PdQuS8p4AF0/CXIYy3ctRkzNFFBaxBwZXWnx613vK+BMKM8B rO2JOL9z2mE68qTfy0eY/Y8yE4xRycgg37wOVKJ6XSJF0yDjcIevfRPPP3m8Gt87 2Gzd0XRXSxH9OBFclqvjL/7I+3Gce4AdCT1zS1HsAGl9VX0UeOR17xconEzsDliE IIz3XoG21Mh2x/G4vTGOuUf6AGzSlkETaDCpHT4dS08Pz4Tnh5QvMdvxxW7RAyZy J24q5TzNxZv1jSxCYj7rLbj45bA+00QnrxOMUBrNOqGlaSCTv7oQQFP2SgtzvoV0 fiXfmwql3PB48w4zznAlwI3o1ugGj00iEJYi1Yov8jxUULknigY5aDJzTarmRG1z L4gRrT8t0ZsD+g== =YyGq -----END PGP SIGNATURE----- --==-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue May 25 15:03:01 2021 Received: (at 48118) by debbugs.gnu.org; 25 May 2021 19:03:01 +0000 Received: from localhost ([127.0.0.1]:46753 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1llcKT-0000o9-1z for submit@debbugs.gnu.org; Tue, 25 May 2021 15:03:01 -0400 Received: from quimby.gnus.org ([95.216.78.240]:48392) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1llcKQ-0000nt-SB for 48118@debbugs.gnu.org; Tue, 25 May 2021 15:03:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: 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=U4qvMoGOlQkR2hJAopL79YqnW0x6LoQj2e4A3gB+tDk=; b=aXIDzQRxlmTWJYEzHZ/onAF8+c N/iQ/eX+esWYq6zHYDIQQpa5XamnZ+Qdbqt2rcFFmI3EF2ktjg6Bhan5JP5X1c/wgaIAwUTD4qWGz 7vyQFbU42PW8Ha+U8+zGycqM0e2oA0olBonKUy3Z+PGs7g6jJr1Op5GRvnpQvXNeS0ME=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1llcKH-0003wb-15; Tue, 25 May 2021 21:02:51 +0200 From: Lars Ingebrigtsen To: Subject: Re: bug#48118: 27.1; 28; Only first process receives output with multiple running processes References: <86bl8z7sgk.fsf@miha-pc> <83im37cac6.fsf@gnu.org> <868s427sg1.fsf@miha-pc> <83pmxebuv7.fsf@gnu.org> <86tumq4rou.fsf@miha-pc> X-Now-Playing: Ultra Milkmaids's _Mort Aux Vaches_: "Vor-juble 2" Date: Tue, 25 May 2021 21:02:48 +0200 In-Reply-To: <86tumq4rou.fsf@miha-pc> (miha@kamnitnik.top's message of "Tue, 25 May 2021 20:02:57 +0200") Message-ID: <87v976prfr.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: writes: > Tanks for feedback, posting revised patch. I did some testing, and the network processes seem to work fine with this change, so I've applied the patch and pushed to Emacs 28 now. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: writes: > Tanks for feedback, posting revised patch. I did some testing, and the network processes seem to work fine with this change, so I've applied the patch and pushed to Emacs 28 now. Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: kamnitnik.top (top)] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [95.216.78.240 listed in list.dnswl.org] X-Debbugs-Envelope-To: 48118 Cc: mail@daniel-mendler.de, Eli Zaretskii , 48118@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) writes: > Tanks for feedback, posting revised patch. I did some testing, and the network processes seem to work fine with this change, so I've applied the patch and pushed to Emacs 28 now. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Tue May 25 15:03:08 2021 Received: (at control) by debbugs.gnu.org; 25 May 2021 19:03:08 +0000 Received: from localhost ([127.0.0.1]:46757 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1llcKa-0000os-8p for submit@debbugs.gnu.org; Tue, 25 May 2021 15:03:08 -0400 Received: from quimby.gnus.org ([95.216.78.240]:48406) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1llcKW-0000o1-68 for control@debbugs.gnu.org; Tue, 25 May 2021 15:03:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Z0iTWsosebhPEXVnkLRgz7YIFwalm/sycI1cR9yCJBU=; b=Z7GRntrLcWZQ+rAZ3Lik0NegdK ISLMjB7oJLcF4l3gm49+s+zZAmAjFI9nNdlmvtO5PcYZYehOWyIO+dyO5XOL01wz02qi0hQ6sZLgD KNixAFVjPlVcfjTJ+jpX/HGv9ysi0Jgy4ck/Pn/SuhVzLsalf+GdMUBVwlF3fjRijdIs=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1llcKO-0003wk-MB for control@debbugs.gnu.org; Tue, 25 May 2021 21:02:58 +0200 Date: Tue, 25 May 2021 21:02:56 +0200 Message-Id: <87tumqprfj.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #48118 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: tags 48118 fixed close 48118 28.1 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) tags 48118 fixed close 48118 28.1 quit From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 04 09:35:10 2021 Received: (at 48118) by debbugs.gnu.org; 4 Jun 2021 13:35:10 +0000 Received: from localhost ([127.0.0.1]:45843 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lp9yc-0001wn-Fr for submit@debbugs.gnu.org; Fri, 04 Jun 2021 09:35:09 -0400 Received: from mail-wr1-f54.google.com ([209.85.221.54]:33664) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lp9yW-0001wA-KH for 48118@debbugs.gnu.org; Fri, 04 Jun 2021 09:35:05 -0400 Received: by mail-wr1-f54.google.com with SMTP id a20so9401744wrc.0 for <48118@debbugs.gnu.org>; Fri, 04 Jun 2021 06:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Bc9Od9+sS9JZ2yLFYGBbA3r/YpKU2y6kUQC3ZEQwJiQ=; b=aWg3NkkSTkIMJCvisdlQ5dq3o1Rrx1dEObtAnCT6VZJdBannOC0h8rp2a5qt4/s+9D QH6kBPKxeO8+SfluFeCj6Sd7iuHwmNP+hcD8I8a5h/DmH8GDCRVDIiC9xbIHsCviidy0 PKi/IsD1+jvipriflW/rwFhqugOrcrKpg1tX+E3Ks/70HmXyBIUpI+5gr2gkUII02U4j UkSW+w0rqvkh2jbZwPkOeD9VZA0RDjYLSealY1FWSN6hDy5Rhy58e1dK2B+/+KE0mnhf kh9y96iv5OdsOvegX1uA+dDwZrij4xoroB+D58i8bEi4ZmiRRPLYV7etpw9iVUsyK5sk gdIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Bc9Od9+sS9JZ2yLFYGBbA3r/YpKU2y6kUQC3ZEQwJiQ=; b=GJ87/t3PzlHD/Nla3HqYNXr5KgrWSsU82/MZmJ1Ht0xfCuRAMwVVy55xYpcoeZHWHV mAs3v/aVilNbRV/O7wV6DZveJJaOHxCg08AlEUXNinEMN5miGTEYy52R64+oF1j/N/3q 51s9sKcaoj/fTuTwTVCJw3kh23wii7o0f/JqISDuLMOZBrF0ayh7uOvGFJJ5Rx+c0xPX 7U31T6alz6MuLG7anfdQvR09m+jX4kgc2kwvRewKG9bi2RS5fhiB24vCGE/g+yYwObGB JjHqHPF8DbaWHH1v+VaXq5RZiUUV4kE3Clbri1+Hu5lhiHR/2hZnGspgtHeLhdCpBEPN dnmA== X-Gm-Message-State: AOAM533iar8SDVBL6SZfEJuSSxQwOamvG0eVrvuTFfIhH2rSVlFpjETu MP65ZaXNY+8QKmrgU0sRU20= X-Google-Smtp-Source: ABdhPJyDBtQXtzJvm3JeQdu76VBPirlVEIE6fQTpXMDg0IRWJ+H3A2HSqkwHKioEc+Y0I/1fnMe7Uw== X-Received: by 2002:a5d:58d3:: with SMTP id o19mr4093978wrf.404.1622813694711; Fri, 04 Jun 2021 06:34:54 -0700 (PDT) Received: from smtpclient.apple ([46.128.198.100]) by smtp.gmail.com with ESMTPSA id y6sm8902214wmy.23.2021.06.04.06.34.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Jun 2021 06:34:54 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: Re: bug#48118: 27.1; 28; Only first process receives output with multiple running processes From: Philipp In-Reply-To: <87v981k39m.fsf@gnus.org> Date: Fri, 4 Jun 2021 15:34:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <550D5481-A071-47C4-94F5-2DF4E8E8BA10@gmail.com> 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> <83bl9vbw8h.fsf@gnu.org> <70ea83e2-fc9e-6feb-240c-ed41abac5254@daniel-mendler.de> <87v981k39m.fsf@gnus.org> To: Lars Ingebrigtsen X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 48118 Cc: Daniel Mendler , 48118@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) > Am 02.05.2021 um 09:23 schrieb Lars Ingebrigtsen : >=20 > Daniel Mendler writes: >=20 >> This is what we assumed. Emacs could check the second process the = next >> time. This way one may get a slightly more fair behavior. >=20 > Yes, more fairness in how Emacs handles process output would be nice, > indeed. An alternative approach would be to randomly shuffle the file = descriptors before selecting on them. At least that's what e.g. Go is = doing (see the code starting from "generate permuted order" in = https://golang.org/src/runtime/select.go).= From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 04 10:01:17 2021 Received: (at 48118) by debbugs.gnu.org; 4 Jun 2021 14:01:17 +0000 Received: from localhost ([127.0.0.1]:47613 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpANs-0003J9-Hw for submit@debbugs.gnu.org; Fri, 04 Jun 2021 10:01:17 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48580) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpANn-0003IN-Bv for 48118@debbugs.gnu.org; Fri, 04 Jun 2021 10:01:12 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:36072) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lpANh-0006dY-3P; Fri, 04 Jun 2021 10:01:01 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2241 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 1lpANg-0001pL-Jy; Fri, 04 Jun 2021 10:01:01 -0400 Date: Fri, 04 Jun 2021 17:00:54 +0300 Message-Id: <83zgw5lofd.fsf@gnu.org> From: Eli Zaretskii To: Philipp In-Reply-To: <550D5481-A071-47C4-94F5-2DF4E8E8BA10@gmail.com> (message from Philipp on Fri, 4 Jun 2021 15:34:53 +0200) Subject: Re: bug#48118: 27.1; 28; Only first process receives output with multiple running processes 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> <83bl9vbw8h.fsf@gnu.org> <70ea83e2-fc9e-6feb-240c-ed41abac5254@daniel-mendler.de> <87v981k39m.fsf@gnus.org> <550D5481-A071-47C4-94F5-2DF4E8E8BA10@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 48118 Cc: mail@daniel-mendler.de, larsi@gnus.org, 48118@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Philipp > Date: Fri, 4 Jun 2021 15:34:53 +0200 > Cc: Daniel Mendler , 48118@debbugs.gnu.org > > An alternative approach would be to randomly shuffle the file descriptors before selecting on them. At least that's what e.g. Go is doing (see the code starting from "generate permuted order" in https://golang.org/src/runtime/select.go). We could have such a behavior as an option. But we'd need to make sure the random numbers coming out of that are really random and give each handle the same chance, even for short time durations. From unknown Thu Jun 19 14:05:18 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 03 Jul 2021 11:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator