bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#48118: 27.1; 28; Only first process receives output with multiple ru


From: Eli Zaretskii
Subject: bug#48118: 27.1; 28; Only first process receives output with multiple running processes
Date: Fri, 30 Apr 2021 17:59:00 +0300

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]