Hi HaiJun,

I second Eli's response - if this is really the case we could stop
processing messages at some point and continue later(e. g. we may check if
there is pending user input) . I kindly suggest reporting these issues on
lsp-mode side before jumping into emacs-devel.

Thanks,
Ivan

On Sat, Apr 4, 2020 at 3:18 PM HaiJun Zhang <netjune@outlook.com> wrote:

> 在 2020年3月29日 +0800 AM10:38，Eli Zaretskii <eliz@gnu.org>，写道：
>
> Date: Sun, 29 Mar 2020 09:44:41 +0800
> From: HaiJun Zhang <netjune@outlook.com>
> Cc: monnier@iro.umontreal.ca, rpluim@gmail.com, emacs-devel@gnu.org
>
> For example, when I run find or grep in a directory with plenty of files,
> the output of the subprocess may
> continue for 1 minute, while I can’t stop it.
>
>
> That doesn't use network communications, so it is not relevant to the
> issue at hand.
>
>
> Something like that. It seems that emacs treat them the same.
>
> One of my use case:
> I plan to hack lsp-mode to limit the bandwidth and the message size.
>
> When I use lsp-mode for dart language, It happened that 10000 lines were
> sent to emacs for one completion which cause emacs unresponsive for several
> seconds.
>
> When I use lsp-mode for go language, It happened that 400 messages were
> sent to emacs during one second which cause emacs unresponsive for a
> while.
>
>