Calling url-retrieve-synchronously in a timer

Calling url-retrieve-synchronously in a timer

[Lennart Borgman]

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.

bug#5372: Calling url-retrieve-synchronously in a timer

[Lennart Borgman]

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.

bug#5372: Calling url-retrieve-synchronously in a timer

[Stefan Monnier]

> 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

bug#5372: Calling url-retrieve-synchronously in a timer

[Lennart Borgman]

On Wed, Jan 13, 2010 at 3:43 PM, Stefan Monnier
<monnier@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.

bug#5372: Calling url-retrieve-synchronously in a timer

[Stefan Monnier]

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

bug#5372: Calling url-retrieve-synchronously in a timer

[Lennart Borgman]

On Wed, Jan 13, 2010 at 7:49 PM, Stefan Monnier
<monnier@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?

bug#5372: Calling url-retrieve-synchronously in a timer

[Stefan Monnier]

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

bug#5372: Calling url-retrieve-synchronously in a timer

[Chong Yidong]

Stefan Monnier <monnier@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

bug#5372: Calling url-retrieve-synchronously in a timer

[Lennart Borgman]

On Wed, Jan 13, 2010 at 5:02 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
> Stefan Monnier <monnier@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?

bug#5372: Calling url-retrieve-synchronously in a timer

[Jason Rumney]

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.

bug#5372: Calling url-retrieve-synchronously in a timer

[Stefan Monnier]

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

bug#5372: Calling url-retrieve-synchronously in a timer

[Jason Rumney]

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.

bug#5372: Calling url-retrieve-synchronously in a timer

[Lars Magne Ingebrigtsen]

Lennart Borgman <lennart.borgman@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/

bug#5372: Calling url-retrieve-synchronously in a timer

[Stefan Monnier]

> 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

bug#5372: Calling url-retrieve-synchronously in a timer

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@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/