GNU bug report logs - #19860
25.0.50; One url-retrieve-synchronously call running concurrently with another can freeze it

Previous Next

Full log

Message #52 received at 19860 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 19860 <at> debbugs.gnu.org
Subject: Re: bug#19860: 25.0.50;
 One url-retrieve-synchronously call running concurrently with another
 can freeze it
Date: Fri, 25 Dec 2015 19:34:09 +0100

Dmitry Gutov <dgutov <at> yandex.ru> writes:

> This applies both to master and emacs-24 (with a caveat).
>
> With sufficiently suitable server, calling long-ops-now or long-ops-idle
> can lead to the "outer" request never returning:
>
> (defun long-ops-idle ()
>   (interactive)
>   (run-with-idle-timer 0.2 nil #'long-outer-op)
>   (run-with-idle-timer 0.5 nil #'long-inner-op))
>
> (defun long-ops-now ()
>   (interactive)
>   (run-with-timer 0.2 nil #'long-inner-op)
>   (long-outer-op))
>
> (defun long-outer-op ()
>   (message "retrieving outer")
>   (url-retrieve-synchronously "http://localhost:9292")
>   (message "outer retrieved"))
>
> (defun long-inner-op ()
>   (message "retrieving inner")
>   (url-retrieve-synchronously "http://localhost:9292")
>   (message "inner retrieved"))
>
> The window freezes, the last message in the echo area being "inner
> retrieved" (but C-g breaks out of it, and if we're calling
> `long-ops-idle', the "outer" request succeeds, too).

It's unclear from the bug thread whether this is still a problem or
not...  Are you still seeing this?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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