* 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 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 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 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).