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

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

bug#49682: 27.2.50; accept-process-output within accept-process-output h


From: Dmitry Gutov
Subject: bug#49682: 27.2.50; accept-process-output within accept-process-output hangs emacs
Date: Fri, 23 Jul 2021 21:30:54 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

On 22.07.2021 08:47, Eli Zaretskii wrote:
From: Lars Ingebrigtsen <larsi@gnus.org>
Cc: Rajeev N <rajeev.jnk@sivalik.com>,  49682@debbugs.gnu.org
Date: Wed, 21 Jul 2021 23:32:16 +0200

Eli Zaretskii <eliz@gnu.org> writes:

(let () (run-with-timer 0 nil #'url-retrieve "https://www.gnu.org/";
#'ignore) (diary-mail-entries))

Don't do that, because it will hurt.  Mixing timers with subprocesses
is asking for trouble.

That's not my experience, really -- url-queue.el is based around firing
off `url-retrieve' from timers, and I've never seen any problems.

Sheer luck, IMO.

I don't really understand the need to run subprocesses from timers,
since subprocess support already includes async operation and built-in
time-outs.

This is a fairly common configuration. Consider a minimal IDE setup:

1. Code completion popup which is shown when Emacs is idle for XX ms.
2. Eldoc hints which are shown at YY ms after the user stops typing.

When both are implemented using HTTP calls, you get "timers with subprocesses".

In fact, I have a configuration like that (based on url.el) and get an occasional strong freeze (one that requires 3 C-g's to get out of) about once every 1-2 weeks. Haven't found a solid repro so far, so if the reporter has something stable-ish, I'll be following this report intently.





reply via email to

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