unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#5372: Calling url-retrieve-synchronously in a timer
       [not found] <e01d8a51001122054x7d2489eu6cf17ca3579368d4@mail.gmail.com>
@ 2010-01-13  9:21 ` Lennart Borgman
  2010-01-13 14:43   ` Stefan Monnier
                     ` (2 more replies)
  0 siblings, 3 replies; 14+ messages in thread
From: Lennart Borgman @ 2010-01-13  9:21 UTC (permalink / raw)
  To: emacs-pretest-bug

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.






^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#5372: Calling url-retrieve-synchronously in a timer
  2010-01-13  9:21 ` bug#5372: Calling url-retrieve-synchronously in a timer Lennart Borgman
@ 2010-01-13 14:43   ` Stefan Monnier
  2010-01-13 15:17     ` Lennart Borgman
  2010-01-13 16:02     ` Chong Yidong
  2011-09-18 10:26   ` Lars Magne Ingebrigtsen
  2011-09-19 18:39   ` Stefan Monnier
  2 siblings, 2 replies; 14+ messages in thread
From: Stefan Monnier @ 2010-01-13 14:43 UTC (permalink / raw)
  To: Lennart Borgman; +Cc: 5372

> 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






^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#5372: Calling url-retrieve-synchronously in a timer
  2010-01-13 14:43   ` Stefan Monnier
@ 2010-01-13 15:17     ` Lennart Borgman
  2010-01-13 18:49       ` Stefan Monnier
  2010-01-13 16:02     ` Chong Yidong
  1 sibling, 1 reply; 14+ messages in thread
From: Lennart Borgman @ 2010-01-13 15:17 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 5372

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.






^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#5372: Calling url-retrieve-synchronously in a timer
  2010-01-13 14:43   ` Stefan Monnier
  2010-01-13 15:17     ` Lennart Borgman
@ 2010-01-13 16:02     ` Chong Yidong
  2010-01-13 16:21       ` Lennart Borgman
  2010-01-13 22:54       ` Jason Rumney
  1 sibling, 2 replies; 14+ messages in thread
From: Chong Yidong @ 2010-01-13 16:02 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 5372

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






^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#5372: Calling url-retrieve-synchronously in a timer
  2010-01-13 16:02     ` Chong Yidong
@ 2010-01-13 16:21       ` Lennart Borgman
  2010-01-13 22:54       ` Jason Rumney
  1 sibling, 0 replies; 14+ messages in thread
From: Lennart Borgman @ 2010-01-13 16:21 UTC (permalink / raw)
  To: Chong Yidong; +Cc: 5372

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?






^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#5372: Calling url-retrieve-synchronously in a timer
  2010-01-13 15:17     ` Lennart Borgman
@ 2010-01-13 18:49       ` Stefan Monnier
  2010-01-13 19:09         ` Lennart Borgman
  0 siblings, 1 reply; 14+ messages in thread
From: Stefan Monnier @ 2010-01-13 18:49 UTC (permalink / raw)
  To: Lennart Borgman; +Cc: 5372

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






^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#5372: Calling url-retrieve-synchronously in a timer
  2010-01-13 18:49       ` Stefan Monnier
@ 2010-01-13 19:09         ` Lennart Borgman
  2010-01-13 19:57           ` Stefan Monnier
  0 siblings, 1 reply; 14+ messages in thread
From: Lennart Borgman @ 2010-01-13 19:09 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 5372

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?






^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#5372: Calling url-retrieve-synchronously in a timer
  2010-01-13 19:09         ` Lennart Borgman
@ 2010-01-13 19:57           ` Stefan Monnier
  0 siblings, 0 replies; 14+ messages in thread
From: Stefan Monnier @ 2010-01-13 19:57 UTC (permalink / raw)
  To: Lennart Borgman; +Cc: 5372

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






^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#5372: Calling url-retrieve-synchronously in a timer
  2010-01-13 16:02     ` Chong Yidong
  2010-01-13 16:21       ` Lennart Borgman
@ 2010-01-13 22:54       ` Jason Rumney
  2010-01-14  4:33         ` Stefan Monnier
  1 sibling, 1 reply; 14+ messages in thread
From: Jason Rumney @ 2010-01-13 22:54 UTC (permalink / raw)
  To: Chong Yidong; +Cc: 5372

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.









^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#5372: Calling url-retrieve-synchronously in a timer
  2010-01-13 22:54       ` Jason Rumney
@ 2010-01-14  4:33         ` Stefan Monnier
  2010-01-14  5:21           ` Jason Rumney
  0 siblings, 1 reply; 14+ messages in thread
From: Stefan Monnier @ 2010-01-14  4:33 UTC (permalink / raw)
  To: Jason Rumney; +Cc: Chong Yidong, 5372

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







^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#5372: Calling url-retrieve-synchronously in a timer
  2010-01-14  4:33         ` Stefan Monnier
@ 2010-01-14  5:21           ` Jason Rumney
  0 siblings, 0 replies; 14+ messages in thread
From: Jason Rumney @ 2010-01-14  5:21 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Chong Yidong, 5372

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.








^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#5372: Calling url-retrieve-synchronously in a timer
  2010-01-13  9:21 ` bug#5372: Calling url-retrieve-synchronously in a timer Lennart Borgman
  2010-01-13 14:43   ` Stefan Monnier
@ 2011-09-18 10:26   ` Lars Magne Ingebrigtsen
  2011-09-19 18:39   ` Stefan Monnier
  2 siblings, 0 replies; 14+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-09-18 10:26 UTC (permalink / raw)
  To: Lennart Borgman; +Cc: 5372

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/





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#5372: Calling url-retrieve-synchronously in a timer
  2010-01-13  9:21 ` bug#5372: Calling url-retrieve-synchronously in a timer Lennart Borgman
  2010-01-13 14:43   ` Stefan Monnier
  2011-09-18 10:26   ` Lars Magne Ingebrigtsen
@ 2011-09-19 18:39   ` Stefan Monnier
  2012-01-07  4:33     ` Lars Magne Ingebrigtsen
  2 siblings, 1 reply; 14+ messages in thread
From: Stefan Monnier @ 2011-09-19 18:39 UTC (permalink / raw)
  To: Lennart Borgman; +Cc: 5372

> 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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#5372: Calling url-retrieve-synchronously in a timer
  2011-09-19 18:39   ` Stefan Monnier
@ 2012-01-07  4:33     ` Lars Magne Ingebrigtsen
  0 siblings, 0 replies; 14+ messages in thread
From: Lars Magne Ingebrigtsen @ 2012-01-07  4:33 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 5372

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/





^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2012-01-07  4:33 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <e01d8a51001122054x7d2489eu6cf17ca3579368d4@mail.gmail.com>
2010-01-13  9:21 ` bug#5372: Calling url-retrieve-synchronously in a timer Lennart Borgman
2010-01-13 14:43   ` Stefan Monnier
2010-01-13 15:17     ` Lennart Borgman
2010-01-13 18:49       ` Stefan Monnier
2010-01-13 19:09         ` Lennart Borgman
2010-01-13 19:57           ` Stefan Monnier
2010-01-13 16:02     ` Chong Yidong
2010-01-13 16:21       ` Lennart Borgman
2010-01-13 22:54       ` Jason Rumney
2010-01-14  4:33         ` Stefan Monnier
2010-01-14  5:21           ` Jason Rumney
2011-09-18 10:26   ` Lars Magne Ingebrigtsen
2011-09-19 18:39   ` Stefan Monnier
2012-01-07  4:33     ` Lars Magne Ingebrigtsen

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).