unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Daniel Mendler <mail@daniel-mendler.de>
Cc: 48118@debbugs.gnu.org
Subject: bug#48118: 27.1; 28; Only first process receives output with multiple running processes
Date: Fri, 30 Apr 2021 17:59:00 +0300	[thread overview]
Message-ID: <83o8dvbyyz.fsf@gnu.org> (raw)
In-Reply-To: <c2e637e2-e855-cfb8-b2eb-ff5105428f63@daniel-mendler.de> (message from Daniel Mendler on Fri, 30 Apr 2021 16:45:25 +0200)

> 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	other threads:[~2021-04-30 14:59 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-30 13:44 bug#48118: 27.1; 28; Only first process receives output with multiple running processes Daniel Mendler
2021-04-30 14:17 ` Eli Zaretskii
2021-04-30 14:23   ` Daniel Mendler
2021-04-30 14:31     ` Eli Zaretskii
2021-04-30 14:26   ` Eli Zaretskii
2021-04-30 14:30     ` Daniel Mendler
2021-04-30 14:34       ` Eli Zaretskii
2021-04-30 14:45         ` Daniel Mendler
2021-04-30 14:59           ` Eli Zaretskii [this message]
2021-04-30 15:39             ` Daniel Mendler
2021-04-30 15:58               ` Eli Zaretskii
2021-04-30 16:17                 ` Daniel Mendler
2021-04-30 18:06                   ` Eli Zaretskii
2021-05-02  7:23                   ` Lars Ingebrigtsen
2021-05-24 21:05                     ` miha--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-05-25 11:38                       ` Eli Zaretskii
2021-05-25 15:18                         ` miha--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-05-25 17:12                           ` Eli Zaretskii
2021-05-25 18:02                             ` miha--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-05-25 19:02                               ` Lars Ingebrigtsen
2021-06-04 13:34                     ` Philipp
2021-06-04 14:00                       ` Eli Zaretskii
2021-04-30 16:15               ` jakanakaevangeli
2021-04-30 17:52                 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83o8dvbyyz.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=48118@debbugs.gnu.org \
    --cc=mail@daniel-mendler.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).