GNU bug report logs - #49682
27.2.50; accept-process-output within accept-process-output hangs emacs

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: rajeev.jnk <at> sivalik.com, 49682 <at> debbugs.gnu.org
Subject: bug#49682: 27.2.50; accept-process-output within accept-process-output hangs emacs
Date: Fri, 23 Jul 2021 21:30:54 +0300

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

Previous Next

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