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

Previous Next

Full log

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?

Previous Next

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