GNU bug report logs - #48118
27.1; 28; Only first process receives output with multiple running processes

Previous Next

Full log

Message #20 received at 48118 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 48118 <at> debbugs.gnu.org
Subject: Re: bug#48118: 27.1; 28; Only first process receives output with
 multiple running processes
Date: Fri, 30 Apr 2021 17:31:09 +0300

> Cc: 48118 <at> debbugs.gnu.org
> From: Daniel Mendler <mail <at> daniel-mendler.de>
> 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"?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.