GNU bug report logs - #5372
Calling url-retrieve-synchronously in a timer

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 5372 in the body.
You can then email your comments to 5372 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: emacs-pretest-bug <at> gnu.org
Subject: Calling url-retrieve-synchronously in a timer
Date: Wed, 13 Jan 2010 10:21:18 +0100

It looks like url-retrieve-synchronously is not finished when run in a
timer. Is that expected behaviour?

It looks like it hangs in accept-process-output.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: 5372 <at> debbugs.gnu.org
Subject: Re: bug#5372: Calling url-retrieve-synchronously in a timer
Date: Wed, 13 Jan 2010 09:43:03 -0500

> It looks like url-retrieve-synchronously is not finished when run in a
> timer.  Is that expected behaviour?
> It looks like it hangs in accept-process-output.

It's not expected (for me anyway), but I'm not completely
surprised either.  Furthermore, it doesn't look like a good thing to
do anyway: timer code should not run for an indefinite amount of time,
so you should probably use url-retrieve instead.


        Stefan

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

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 5372 <at> debbugs.gnu.org
Subject: Re: bug#5372: Calling url-retrieve-synchronously in a timer
Date: Wed, 13 Jan 2010 16:17:49 +0100

On Wed, Jan 13, 2010 at 3:43 PM, Stefan Monnier
<monnier <at> iro.umontreal.ca> wrote:
>> It looks like url-retrieve-synchronously is not finished when run in a
>> timer.  Is that expected behaviour?
>> It looks like it hangs in accept-process-output.
>
> It's not expected (for me anyway), but I'm not completely
> surprised either.


So do you consider it a bug? Or should it rather be documented for the
moment? Does it work the same way on other platforms? (I tested on
w32, forgot to mention that.)


> Furthermore, it doesn't look like a good thing to
> do anyway: timer code should not run for an indefinite amount of time,


Maybe you misunderstod me. If I do the call to
url-retrieve-synchronously from the command loop it finishes very
quickly (in this case), but if I do the same thing in a timer it
hangs.


> so you should probably use url-retrieve instead.


Thanks. Yes, I already did and that solved my problem, but the bug
report is not about that.

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Lennart Borgman <lennart.borgman <at> gmail.com>, 5372 <at> debbugs.gnu.org
Subject: Re: bug#5372: Calling url-retrieve-synchronously in a timer
Date: Wed, 13 Jan 2010 11:02:56 -0500

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> It looks like url-retrieve-synchronously is not finished when run in a
>> timer.  Is that expected behaviour?
>> It looks like it hangs in accept-process-output.
>
> It's not expected (for me anyway), but I'm not completely
> surprised either.  Furthermore, it doesn't look like a good thing to
> do anyway: timer code should not run for an indefinite amount of time,
> so you should probably use url-retrieve instead.

Could this be a manifestation of Bug#5359, "process-send-region hangs
ntEmacs if region >64K"?

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5359

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

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 5372 <at> debbugs.gnu.org
Subject: Re: bug#5372: Calling url-retrieve-synchronously in a timer
Date: Wed, 13 Jan 2010 17:21:20 +0100

On Wed, Jan 13, 2010 at 5:02 PM, Chong Yidong <cyd <at> stupidchicken.com> wrote:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
>>> It looks like url-retrieve-synchronously is not finished when run in a
>>> timer.  Is that expected behaviour?
>>> It looks like it hangs in accept-process-output.
>>
>> It's not expected (for me anyway), but I'm not completely
>> surprised either.  Furthermore, it doesn't look like a good thing to
>> do anyway: timer code should not run for an indefinite amount of time,
>> so you should probably use url-retrieve instead.
>
> Could this be a manifestation of Bug#5359, "process-send-region hangs
> ntEmacs if region >64K"?
>
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5359


The buffer retrieved in my case has point-max 53784.

I tested with a smaller web page and that actually worked. But to my
surprise the original web page also works today.

I do not know what is different. However I have seen several times
that Emacs on w32 can get into bad states. This happens when some kind
of resource is exhausted. The one I can see easily is GDI.

Maybe some of the w32 api calls does not check the return values as they should?

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: 5372 <at> debbugs.gnu.org
Subject: Re: bug#5372: Calling url-retrieve-synchronously in a timer
Date: Wed, 13 Jan 2010 13:49:09 -0500

>>> It looks like url-retrieve-synchronously is not finished when run in a
>>> timer.  Is that expected behaviour?
>>> It looks like it hangs in accept-process-output.
>> It's not expected (for me anyway), but I'm not completely
>> surprised either.
> So do you consider it a bug?

I think so, yes.

>> Furthermore, it doesn't look like a good thing to
>> do anyway: timer code should not run for an indefinite amount of time,
> Maybe you misunderstod me.  If I do the call to
> url-retrieve-synchronously from the command loop it finishes very
> quickly (in this case), but if I do the same thing in a timer
> it hangs.

I understood you alright.  The fact that "it finishes quickly" when you
try it doesn't mean that it will always run in a definite amount of time.


        Stefan

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

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 5372 <at> debbugs.gnu.org
Subject: Re: bug#5372: Calling url-retrieve-synchronously in a timer
Date: Wed, 13 Jan 2010 20:09:14 +0100

On Wed, Jan 13, 2010 at 7:49 PM, Stefan Monnier
<monnier <at> iro.umontreal.ca> wrote:
>
>>> Furthermore, it doesn't look like a good thing to
>>> do anyway: timer code should not run for an indefinite amount of time,
>> Maybe you misunderstod me.  If I do the call to
>> url-retrieve-synchronously from the command loop it finishes very
>> quickly (in this case), but if I do the same thing in a timer
>> it hangs.
>
> I understood you alright.  The fact that "it finishes quickly" when you
> try it doesn't mean that it will always run in a definite amount of time.


What is the problem with letting code in a timer run/wait for a long time?

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: 5372 <at> debbugs.gnu.org
Subject: Re: bug#5372: Calling url-retrieve-synchronously in a timer
Date: Wed, 13 Jan 2010 14:57:58 -0500

>>>> Furthermore, it doesn't look like a good thing to
>>>> do anyway: timer code should not run for an indefinite amount of time,
>>> Maybe you misunderstod me.  If I do the call to
>>> url-retrieve-synchronously from the command loop it finishes very
>>> quickly (in this case), but if I do the same thing in a timer
>>> it hangs.
>> I understood you alright.  The fact that "it finishes quickly" when you
>> try it doesn't mean that it will always run in a definite amount of time.
> What is the problem with letting code in a timer run/wait for a long time?

Since it's run asynchronously, it can interrupt the user unexpectedly.

Also timer code is normally run with inhibit-quit non-nil, so the user
has no way to abort the timer code.  So you'd need to use
with-local-quit at least, which in turn means that if the user happens
to press C-g while your timer happens to be running, it will be aborted.


        Stefan

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

From: Jason Rumney <jasonr <at> gnu.org>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 5372 <at> debbugs.gnu.org
Subject: Re: bug#5372: Calling url-retrieve-synchronously in a timer
Date: Thu, 14 Jan 2010 06:54:21 +0800

Chong Yidong wrote:
>>> It looks like url-retrieve-synchronously is not finished when run in a
>>> timer.  Is that expected behaviour?
>>> It looks like it hangs in accept-process-output.
>>>       
>
> Could this be a manifestation of Bug#5359, "process-send-region hangs
> ntEmacs if region >64K"?
>
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5359
>   

url-retrieve-synchronously should not be using a subprocess, so unlikely.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Jason Rumney <jasonr <at> gnu.org>
Cc: Chong Yidong <cyd <at> stupidchicken.com>, 5372 <at> debbugs.gnu.org
Subject: Re: bug#5372: Calling url-retrieve-synchronously in a timer
Date: Wed, 13 Jan 2010 23:33:43 -0500

>>>> It looks like url-retrieve-synchronously is not finished when run in a
>>>> timer.  Is that expected behaviour?
>>>> It looks like it hangs in accept-process-output.
>> Could this be a manifestation of Bug#5359, "process-send-region hangs
>> ntEmacs if region >64K"?
>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5359
> url-retrieve-synchronously should not be using a subprocess, so unlikely.

It does use a subprocess.  But it typically doesn't send much data via
process-send-region (tho it can easily receive a lot of data from such
processes).


        Stefan

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

From: Jason Rumney <jasonr <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Chong Yidong <cyd <at> stupidchicken.com>, 5372 <at> debbugs.gnu.org
Subject: Re: bug#5372: Calling url-retrieve-synchronously in a timer
Date: Thu, 14 Jan 2010 13:21:33 +0800

On 14/01/2010 12:33, Stefan Monnier wrote:
>> url-retrieve-synchronously should not be using a subprocess, so unlikely.
>>      
> It does use a subprocess.  But it typically doesn't send much data via
> process-send-region (tho it can easily receive a lot of data from such
> processes).
>    

The "subprocess" it uses should be a network socket, not a real 
subprocess.  The lisp interface is the same, but I am fairly certain 
that bug#5359 is caused by a limitation in Windows stdio buffering 
between processes, not by anything internal to Emacs, so it should only 
affect real subprocesses.

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

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: 5372 <at> debbugs.gnu.org
Subject: Re: Calling url-retrieve-synchronously in a timer
Date: Sun, 18 Sep 2011 12:26:33 +0200

Lennart Borgman <lennart.borgman <at> gmail.com> writes:

> It looks like url-retrieve-synchronously is not finished when run in a
> timer. Is that expected behaviour?
>
> It looks like it hangs in accept-process-output.

Is this still a problem with the current Emacs 24?

Using `accept-process-output' from a timer should work, I think.  In
case this still doesn't work, do you have a test case to reproduce the
bug?

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

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: 5372 <at> debbugs.gnu.org
Subject: Re: bug#5372: Calling url-retrieve-synchronously in a timer
Date: Mon, 19 Sep 2011 14:39:32 -0400

> It looks like url-retrieve-synchronously is not finished when run in a
> timer.  Is that expected behaviour?
> It looks like it hangs in accept-process-output.

I don't think there's a deep reason why url-retrieve-synchronously can't
run from a timer.  If you find a problem with it, please make a proper
bug report, with the usual detailed information.
Note that url-retrieve-synchronously may block for indefinite amounts of
time waiting for some remote host to answer, so if run from a timer,
you'll need/want with-local-quit (or while-no-input) so the user can
interrupt it if needed.


        Stefan

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

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Lennart Borgman <lennart.borgman <at> gmail.com>, 5372 <at> debbugs.gnu.org
Subject: Re: bug#5372: Calling url-retrieve-synchronously in a timer
Date: Sat, 07 Jan 2012 05:33:31 +0100

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> I don't think there's a deep reason why url-retrieve-synchronously can't
> run from a timer.  If you find a problem with it, please make a proper
> bug report, with the usual detailed information.

More information was requested, but no response was given within a few
months, so I'm closing this bug report.  If the problem still exists,
please reopen this bug report.

-- 
(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.