From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 13 04:21:45 2010 Received: (at submit) by debbugs.gnu.org; 13 Jan 2010 09:21:45 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NUzQ9-0005RA-JB for submit@debbugs.gnu.org; Wed, 13 Jan 2010 04:21:45 -0500 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NUzQ7-0005R1-58 for submit@debbugs.gnu.org; Wed, 13 Jan 2010 04:21:43 -0500 Received: from mail.gnu.org ([199.232.76.166]:33609 helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NUzQ4-000066-DJ for emacs-pretest-bug@gnu.org; Wed, 13 Jan 2010 04:21:40 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NUzQ3-0003Jq-DH for emacs-pretest-bug@gnu.org; Wed, 13 Jan 2010 04:21:40 -0500 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on monty-python X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from mail-fx0-f228.google.com ([209.85.220.228]:44983) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NUzQ2-0003Jc-Ur for emacs-pretest-bug@gnu.org; Wed, 13 Jan 2010 04:21:39 -0500 Received: by fxm28 with SMTP id 28so14751501fxm.26 for ; Wed, 13 Jan 2010 01:21:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=sfHqFHw2yvNO0EnJzcFYVEPF5TvvvVp2ktMbjyc4YGc=; b=Ddl8lZQAN7EtTeDNrVL3JtHxiWFGdVvrHFDfrd9dXG0fJGR6uiB16q7GPcp6zbssea sBwewZdX3psqdddG86GbWVc5qsOrN4j86JlWO0AAJh4Au5KLU77ga8mJyaAzaZr0l+lV I92lNm3BYc88+k7AwJEFOKh1KpxjWffSY1jlE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=RJFk9ABkhrb8/yBITaU8ZU+eoqfkw/ELLfB8OLWvx1bcZmlJTYdM+Wc3enTj3D/SLe ivhG3OJjlTZL2bz4lQ9W3/dSbo+PkTzaTUp8KrBEFEURLg9mU+V9XmerDuGITckeiF5b yv2GM9E27ThzcbvmAWaxTrc5ZDxa0FlTaIwCk= MIME-Version: 1.0 Received: by 10.239.189.76 with SMTP id s12mr487477hbh.111.1263374498090; Wed, 13 Jan 2010 01:21:38 -0800 (PST) In-Reply-To: References: From: Lennart Borgman Date: Wed, 13 Jan 2010 10:21:18 +0100 Message-ID: Subject: Calling url-retrieve-synchronously in a timer To: emacs-pretest-bug@gnu.org Content-Type: text/plain; charset=UTF-8 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-Spam-Score: -4.5 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.5 (----) 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. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 13 09:43:11 2010 Received: (at 5372) by debbugs.gnu.org; 13 Jan 2010 14:43:11 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NV4RC-000221-PM for submit@debbugs.gnu.org; Wed, 13 Jan 2010 09:43:10 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.183] helo=ironport2-out.pppoe.ca) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NV4RA-00021u-TJ for 5372@debbugs.gnu.org; Wed, 13 Jan 2010 09:43:09 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAMNqTUvO+KPG/2dsb2JhbACBRNUyhDAEijI X-IronPort-AV: E=Sophos;i="4.49,268,1262581200"; d="scan'208";a="53667114" Received: from 206-248-163-198.dsl.teksavvy.com (HELO pastel.home) ([206.248.163.198]) by ironport2-out.pppoe.ca with ESMTP; 13 Jan 2010 09:43:03 -0500 Received: by pastel.home (Postfix, from userid 20848) id 7BB00806E; Wed, 13 Jan 2010 09:43:03 -0500 (EST) From: Stefan Monnier To: Lennart Borgman Subject: Re: bug#5372: Calling url-retrieve-synchronously in a timer Message-ID: References: Date: Wed, 13 Jan 2010 09:43:03 -0500 In-Reply-To: (Lennart Borgman's message of "Wed, 13 Jan 2010 10:21:18 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.1 (--) X-Debbugs-Envelope-To: 5372 Cc: 5372@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > 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 From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 13 10:18:19 2010 Received: (at 5372) by debbugs.gnu.org; 13 Jan 2010 15:18:19 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NV4zD-0002Yy-Gv for submit@debbugs.gnu.org; Wed, 13 Jan 2010 10:18:19 -0500 Received: from mail-bw0-f216.google.com ([209.85.218.216]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NV4zB-0002Yf-Lv for 5372@debbugs.gnu.org; Wed, 13 Jan 2010 10:18:18 -0500 Received: by bwz8 with SMTP id 8so15668829bwz.39 for <5372@debbugs.gnu.org>; Wed, 13 Jan 2010 07:18:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=YsOh2g8vqEVtRbbTv8aXLJoY0j8BRWAQLySYiUTVbgs=; b=M0ysLGo9aMS2KgqJQcNtoe8v8Lm1BuUnuEuRQtAoMPKR4HTtPif4xeGM9Rq7TFyzR4 1VIXPFPdLczsNZF3bj5/jFTdkKMdLUMHXIoqt8QPD5MHdxYTPWdPMDenqHQdWpWJfca4 laoAbwjw5LpTqxonS+8zP6SW55k5YqKArbCZo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=ZfQAkUu38FgOKbQLP4S51yIZ1s5oB2kgL2TtilenITO4kLXQ9onOyFCAaFm3BAP/b5 F/P+tiG8P8hxILGNdIuipFjuP6E15Cs11JAIA4OwQqDDNLZ0x9r77zVpVrqWzNuoj3nN AHe1TAWmUXqm5cSoLGLw8bdhXQjynL0J3fZ7I= MIME-Version: 1.0 Received: by 10.239.189.13 with SMTP id r13mr831435hbh.92.1263395889130; Wed, 13 Jan 2010 07:18:09 -0800 (PST) In-Reply-To: References: From: Lennart Borgman Date: Wed, 13 Jan 2010 16:17:49 +0100 Message-ID: Subject: Re: bug#5372: Calling url-retrieve-synchronously in a timer To: Stefan Monnier Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 5372 Cc: 5372@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.9 (--) On Wed, Jan 13, 2010 at 3:43 PM, Stefan Monnier wrote: >> It looks like url-retrieve-synchronously is not finished when run in a >> timer. =C2=A0Is 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. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 13 11:03:04 2010 Received: (at 5372) by debbugs.gnu.org; 13 Jan 2010 16:03:04 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NV5gW-0003A5-EM for submit@debbugs.gnu.org; Wed, 13 Jan 2010 11:03:04 -0500 Received: from pantheon-po19.its.yale.edu ([130.132.50.75]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NV5gT-00039e-Oc for 5372@debbugs.gnu.org; Wed, 13 Jan 2010 11:03:02 -0500 Received: from furry (adsl-99-58-201-143.dsl.wlfrct.sbcglobal.net [99.58.201.143]) (authenticated bits=0) by pantheon-po19.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id o0DG2uFl020300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Jan 2010 11:02:57 -0500 Received: by furry (Postfix, from userid 1000) id 903BCC05D; Wed, 13 Jan 2010 09:02:56 -0700 (MST) From: Chong Yidong To: Stefan Monnier Subject: Re: bug#5372: Calling url-retrieve-synchronously in a timer References: Date: Wed, 13 Jan 2010 11:02:56 -0500 In-Reply-To: (Stefan Monnier's message of "Wed, 13 Jan 2010 09:43:03 -0500") Message-ID: <87y6k20z7z.fsf@stupidchicken.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) X-Spam-Score: -5.6 (-----) X-Debbugs-Envelope-To: 5372 Cc: Lennart Borgman , 5372@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.8 (-----) Stefan Monnier 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 From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 13 11:21:48 2010 Received: (at 5372) by debbugs.gnu.org; 13 Jan 2010 16:21:48 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NV5yd-0003wT-Qf for submit@debbugs.gnu.org; Wed, 13 Jan 2010 11:21:48 -0500 Received: from gv-out-0910.google.com ([216.239.58.190]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NV5yb-0003wN-To for 5372@debbugs.gnu.org; Wed, 13 Jan 2010 11:21:46 -0500 Received: by gv-out-0910.google.com with SMTP id r4so202138gve.37 for <5372@debbugs.gnu.org>; Wed, 13 Jan 2010 08:21:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=LL25tc8RCzMNA64HWtnavCojXuqhcECc4D+5HApT3P0=; b=TK07Vay9x+KKsakC5lshotiCZIQGDhRH5lkSxOUnccLFT9U/RcjARNOpwgQveNU0uA Ebks3FwVGztELobfYoNrotz9jLZGxewENWnhe6VcXXhxQO/J+f28W0SwuoK6udxtdOu2 42LdqiqbY/uukGtbXUbEIEzRlocGLBcbrN8/c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=CUEU0ARb8hvj3NFDcZwIIFto7RMmivuTTtQIlLsyWuE9AZg0Lib80aIvnnxpgPrmLB inRRslBGQnBTJkUzAarDfo1j/3zSdW4pnTr7+/LgUSMP73Is3GySYvHmxntVDBMKweg2 FciD07hwGF0VrISjv4GFS+ow/mvQbNr1KMLek= MIME-Version: 1.0 Received: by 10.239.179.131 with SMTP id d3mr3172279hbg.15.1263399700525; Wed, 13 Jan 2010 08:21:40 -0800 (PST) In-Reply-To: <87y6k20z7z.fsf@stupidchicken.com> References: <87y6k20z7z.fsf@stupidchicken.com> From: Lennart Borgman Date: Wed, 13 Jan 2010 17:21:20 +0100 Message-ID: Subject: Re: bug#5372: Calling url-retrieve-synchronously in a timer To: Chong Yidong Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 5372 Cc: Stefan Monnier , 5372@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On Wed, Jan 13, 2010 at 5:02 PM, Chong Yidong wrote= : > Stefan Monnier writes: > >>> It looks like url-retrieve-synchronously is not finished when run in a >>> timer. =C2=A0Is 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. =C2=A0Furthermore, it doesn't look like a good thing t= o >> 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=3D5359 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 sh= ould? From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 13 13:49:17 2010 Received: (at 5372) by debbugs.gnu.org; 13 Jan 2010 18:49:17 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NV8HM-0006f8-RH for submit@debbugs.gnu.org; Wed, 13 Jan 2010 13:49:16 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181] helo=ironport2-out.pppoe.ca) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NV8HL-0006ew-9J for 5372@debbugs.gnu.org; Wed, 13 Jan 2010 13:49:15 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIEAC+kTUvO+KPG/2dsb2JhbACBRNYRhDAEijI X-IronPort-AV: E=Sophos;i="4.49,269,1262581200"; d="scan'208";a="53687770" Received: from 206-248-163-198.dsl.teksavvy.com (HELO pastel.home) ([206.248.163.198]) by ironport2-out.pppoe.ca with ESMTP; 13 Jan 2010 13:49:10 -0500 Received: by pastel.home (Postfix, from userid 20848) id 8ED4A806E; Wed, 13 Jan 2010 13:49:09 -0500 (EST) From: Stefan Monnier To: Lennart Borgman Subject: Re: bug#5372: Calling url-retrieve-synchronously in a timer Message-ID: References: Date: Wed, 13 Jan 2010 13:49:09 -0500 In-Reply-To: (Lennart Borgman's message of "Wed, 13 Jan 2010 16:17:49 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.1 (--) X-Debbugs-Envelope-To: 5372 Cc: 5372@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) >>> It looks like url-retrieve-synchronously is not finished when run in a >>> timer. =A0Is 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 From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 13 14:09:41 2010 Received: (at 5372) by debbugs.gnu.org; 13 Jan 2010 19:09:41 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NV8b6-0007Wg-He for submit@debbugs.gnu.org; Wed, 13 Jan 2010 14:09:40 -0500 Received: from mail-fx0-f226.google.com ([209.85.220.226]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NV8b5-0007WX-3J for 5372@debbugs.gnu.org; Wed, 13 Jan 2010 14:09:39 -0500 Received: by fxm26 with SMTP id 26so21568197fxm.39 for <5372@debbugs.gnu.org>; Wed, 13 Jan 2010 11:09:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=GqvLUiK5deTMsBGcCU1nqtp86N5SF3vE0DwRuwWOkiU=; b=nUGiKnCu1/9NliH4aWjxHvnWc0yWqquSaGTP09Gcbo9JFZO3tJe8yAzpC9awbCbRjt 2STqQcx9MW/Z68QalCktl1KUF4fMNlAHIQ4OlLBbifyzWZqSUMFb70ij8Cjyp9sBRrmz t/QPs8xA6SSAhMsKwRhz6GaZ4LjfOIrL6BS48= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=dGE8q/7Pu/vpYdqI7EU4Dqj/apsSEEe2mMpJsQ5F3FHtWhBS8IyO4jYnpRQ1CBA9Sh HGoN+nlVzlCspUWxRH/41JtrqR6otd8WD26p6yHBC2XHIq9HR7EhkMow1GiZYfnr9J6p IFbnZSPmpG0+Wnlp1WolKWSo94hFiQKDd7lE0= MIME-Version: 1.0 Received: by 10.239.134.142 with SMTP id 14mr1901866hbz.139.1263409774205; Wed, 13 Jan 2010 11:09:34 -0800 (PST) In-Reply-To: References: From: Lennart Borgman Date: Wed, 13 Jan 2010 20:09:14 +0100 Message-ID: Subject: Re: bug#5372: Calling url-retrieve-synchronously in a timer To: Stefan Monnier Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 5372 Cc: 5372@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.9 (--) On Wed, Jan 13, 2010 at 7:49 PM, Stefan Monnier 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. =C2=A0If 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. =C2=A0The 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? From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 13 14:58:06 2010 Received: (at 5372) by debbugs.gnu.org; 13 Jan 2010 19:58:06 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NV9Lx-0008Kg-VY for submit@debbugs.gnu.org; Wed, 13 Jan 2010 14:58:06 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.183] helo=ironport2-out.pppoe.ca) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NV9Lv-0008KC-Fj for 5372@debbugs.gnu.org; Wed, 13 Jan 2010 14:58:03 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIEAJe0TUvO+KPG/2dsb2JhbACBRNV/hDAEijI X-IronPort-AV: E=Sophos;i="4.49,270,1262581200"; d="scan'208";a="53693412" Received: from 206-248-163-198.dsl.teksavvy.com (HELO pastel.home) ([206.248.163.198]) by ironport2-out.pppoe.ca with ESMTP; 13 Jan 2010 14:57:58 -0500 Received: by pastel.home (Postfix, from userid 20848) id 97A61806E; Wed, 13 Jan 2010 14:57:58 -0500 (EST) From: Stefan Monnier To: Lennart Borgman Subject: Re: bug#5372: Calling url-retrieve-synchronously in a timer Message-ID: References: Date: Wed, 13 Jan 2010 14:57:58 -0500 In-Reply-To: (Lennart Borgman's message of "Wed, 13 Jan 2010 20:09:14 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 5372 Cc: 5372@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) >>>> 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. =A0If 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. =A0The 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 From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 13 17:54:35 2010 Received: (at 5372) by debbugs.gnu.org; 13 Jan 2010 22:54:35 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NVC6l-0003pY-Ia for submit@debbugs.gnu.org; Wed, 13 Jan 2010 17:54:35 -0500 Received: from mail-fx0-f226.google.com ([209.85.220.226]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NVC6k-0003pT-8S for 5372@debbugs.gnu.org; Wed, 13 Jan 2010 17:54:34 -0500 Received: by fxm26 with SMTP id 26so21798673fxm.39 for <5372@debbugs.gnu.org>; Wed, 13 Jan 2010 14:54:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:message-id :date:from:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Ari8zFKaUdg/ksMKWF/1uwDufgogkokqLaml+9sJ/hQ=; b=HeGy7ktipvtWhkFNCauDSmVHFNfTTNuJSGXqO7NQYz/lmsPKrnUFD9CVNLD46b3oA0 N7FRFLwqcbxf552MZqa5CSSWJ7rrN91w7OWkQpOGyDfNxVG+tRwJ+v6cGsZjUHvUJtQu gqJFjKCgI1gex7/Rg0kERKsCr+rmbKER+CifE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=G9vJ+H4r/Zq1Pjb0ZJlY306stgtzyPTXIcyQnjLhqbMBU6f5IKjltxI5QzeRVU5WRz DJtu1M/qysVUZ0YPmRCNHLe7FdrXL3HA4ERkFnsS7456ZZZK2Xs10qF4fzK2aZWDdKXN t8VPBllD/Zi7vklz1zfLXJNHL+GX8EdnJfaY0= Received: by 10.87.71.5 with SMTP id y5mr44530fgk.72.1263423269044; Wed, 13 Jan 2010 14:54:29 -0800 (PST) Received: from wanchan.jasonrumney.net ([115.132.151.241]) by mx.google.com with ESMTPS id 13sm10420fxm.13.2010.01.13.14.54.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 13 Jan 2010 14:54:27 -0800 (PST) Received: from wanchan.jasonrumney.net (localhost [127.0.0.1]) by wanchan.jasonrumney.net (Postfix) with ESMTP id 4DB86825; Thu, 14 Jan 2010 06:54:22 +0800 (MYT) Message-ID: <4B4E4F1D.9090604@gnu.org> Date: Thu, 14 Jan 2010 06:54:21 +0800 From: Jason Rumney User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: Chong Yidong Subject: Re: bug#5372: Calling url-retrieve-synchronously in a timer References: <87y6k20z7z.fsf@stupidchicken.com> In-Reply-To: <87y6k20z7z.fsf@stupidchicken.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 5372 Cc: Stefan Monnier , 5372@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) 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. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 13 23:33:48 2010 Received: (at 5372) by debbugs.gnu.org; 14 Jan 2010 04:33:49 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NVHP2-0007mr-Ao for submit@debbugs.gnu.org; Wed, 13 Jan 2010 23:33:48 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181] helo=ironport2-out.pppoe.ca) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NVHP1-0007mk-Ke for 5372@debbugs.gnu.org; Wed, 13 Jan 2010 23:33:47 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4EAFEtTktFxLLV/2dsb2JhbACBRdZMhDAEijM X-IronPort-AV: E=Sophos;i="4.49,272,1262581200"; d="scan'208";a="53720335" Received: from 69-196-178-213.dsl.teksavvy.com (HELO pastel.home) ([69.196.178.213]) by ironport2-out.pppoe.ca with ESMTP; 13 Jan 2010 23:33:44 -0500 Received: by pastel.home (Postfix, from userid 20848) id 0D5B6806E; Wed, 13 Jan 2010 23:33:43 -0500 (EST) From: Stefan Monnier To: Jason Rumney Subject: Re: bug#5372: Calling url-retrieve-synchronously in a timer Message-ID: References: <87y6k20z7z.fsf@stupidchicken.com> <4B4E4F1D.9090604@gnu.org> Date: Wed, 13 Jan 2010 23:33:43 -0500 In-Reply-To: <4B4E4F1D.9090604@gnu.org> (Jason Rumney's message of "Thu, 14 Jan 2010 06:54:21 +0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -1.7 (-) X-Debbugs-Envelope-To: 5372 Cc: Chong Yidong , 5372@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.8 (-) >>>> 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 14 00:22:27 2010 Received: (at 5372) by debbugs.gnu.org; 14 Jan 2010 05:22:27 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NVIA6-0008Qe-7e for submit@debbugs.gnu.org; Thu, 14 Jan 2010 00:22:26 -0500 Received: from mail-yw0-f203.google.com ([209.85.211.203]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NVIA4-0008QT-DR for 5372@debbugs.gnu.org; Thu, 14 Jan 2010 00:22:24 -0500 Received: by ywh41 with SMTP id 41so39333639ywh.0 for <5372@debbugs.gnu.org>; Wed, 13 Jan 2010 21:22:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=PcYn3HVZjYbocCKtYFkXy30WDXDnGjHavLl87MLGXXQ=; b=hzXM3Oe+QEEVb1nuh3ZndPwi3vp42mrnPkVdJO2DSdA2vsvczJwpk8b8wxjQRZaFoY glI9j7cHyl3OhpQYzI+ZoRmBinFxzpNbAm+AsGgtB0uzjIHpuc+4Z35V9ckh4df3hfnY itlapF/4OdzuhRq15WVrJZqvWiweA5/ypu3LQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=FBjiVu+BeDqWwhD5Hht7wmWekLJTUHNPafyzIUVPx7kFfZa+IRXG1ToUWtGzckMvNV 0SA0t6wzjHZvS+V5UXlTxW7AKjgzr9gVf3ieA75xCDeHPhGC71LPPMj8eHrwAYMDdc9C P0/rlABxUJYQXsMlwOQNQc3PbU+l+ST+pYnMM= Received: by 10.100.243.8 with SMTP id q8mr121042anh.18.1263446540784; Wed, 13 Jan 2010 21:22:20 -0800 (PST) Received: from ?10.1.1.113? ([61.4.103.130]) by mx.google.com with ESMTPS id 4sm4821ywi.9.2010.01.13.21.22.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 13 Jan 2010 21:22:18 -0800 (PST) Message-ID: <4B4EA9DD.1050302@gnu.org> Date: Thu, 14 Jan 2010 13:21:33 +0800 From: Jason Rumney User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Stefan Monnier Subject: Re: bug#5372: Calling url-retrieve-synchronously in a timer References: <87y6k20z7z.fsf@stupidchicken.com> <4B4E4F1D.9090604@gnu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 5372 Cc: Chong Yidong , 5372@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 18 06:35:53 2011 Received: (at 5372) by debbugs.gnu.org; 18 Sep 2011 10:35:53 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R5Ej2-0002Hg-RU for submit@debbugs.gnu.org; Sun, 18 Sep 2011 06:35:53 -0400 Received: from hermes.netfonds.no ([80.91.224.195]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R5Eix-0002HA-9O for 5372@debbugs.gnu.org; Sun, 18 Sep 2011 06:35:48 -0400 Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58] helo=stories.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1R5Ee4-0000MR-TV; Sun, 18 Sep 2011 12:30:44 +0200 From: Lars Magne Ingebrigtsen To: Lennart Borgman Subject: Re: Calling url-retrieve-synchronously in a timer In-Reply-To: (Lennart Borgman's message of "Wed, 13 Jan 2010 10:21:18 +0100") Date: Sun, 18 Sep 2011 12:26:33 +0200 Message-ID: References: User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux) X-Now-Playing: Eurythmics's _Savage_: "Brand New Day" MIME-Version: 1.0 Content-Type: text/plain X-MailScanner-ID: 1R5Ee4-0000MR-TV X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1316946645.77667@yli54x8YlPJuIll7SUNkEw X-Spam-Status: No X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 5372 Cc: 5372@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Lennart Borgman 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/ From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 19 14:44:41 2011 Received: (at 5372) by debbugs.gnu.org; 19 Sep 2011 18:44:41 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R5ipc-0007TW-QN for submit@debbugs.gnu.org; Mon, 19 Sep 2011 14:44:41 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.183] helo=ironport2-out.pppoe.ca) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R5ipY-0007T3-Lo for 5372@debbugs.gnu.org; Mon, 19 Sep 2011 14:44:38 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADSLd05FpZ7x/2dsb2JhbABCpzt4gVMBAQQBViMFCws0EhQYDSSICrQ+hngEoE6ERA X-IronPort-AV: E=Sophos;i="4.68,406,1312171200"; d="scan'208";a="137154159" Received: from 69-165-158-241.dsl.teksavvy.com (HELO pastel.home) ([69.165.158.241]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 19 Sep 2011 14:39:33 -0400 Received: by pastel.home (Postfix, from userid 20848) id ECE25591F1; Mon, 19 Sep 2011 14:39:32 -0400 (EDT) From: Stefan Monnier To: Lennart Borgman Subject: Re: bug#5372: Calling url-retrieve-synchronously in a timer Message-ID: References: Date: Mon, 19 Sep 2011 14:39:32 -0400 In-Reply-To: (Lennart Borgman's message of "Wed, 13 Jan 2010 10:21:18 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 5372 Cc: 5372@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) > 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 06 23:33:40 2012 Received: (at 5372) by debbugs.gnu.org; 7 Jan 2012 04:33:40 +0000 Received: from localhost ([127.0.0.1]:47466 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RjNyO-0002dJ-9N for submit@debbugs.gnu.org; Fri, 06 Jan 2012 23:33:40 -0500 Received: from hermes.netfonds.no ([80.91.224.195]:48541) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RjNyM-0002dA-HG for 5372@debbugs.gnu.org; Fri, 06 Jan 2012 23:33:39 -0500 Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58] helo=stories.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1RjNyG-00022L-4i; Sat, 07 Jan 2012 05:33:32 +0100 From: Lars Magne Ingebrigtsen To: Stefan Monnier Subject: Re: bug#5372: Calling url-retrieve-synchronously in a timer References: X-Now-Playing: Fennesz, Sakamoto's _Flumina (1)_: "0402" Date: Sat, 07 Jan 2012 05:33:31 +0100 In-Reply-To: (Stefan Monnier's message of "Mon, 19 Sep 2011 14:39:32 -0400") Message-ID: User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-MailScanner-ID: 1RjNyG-00022L-4i X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1326515612.38339@9lOWCk1xsCJXUAEATdQxFg X-Spam-Status: No X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 5372 Cc: Lennart Borgman , 5372@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Stefan Monnier 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/ From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 06 23:33:42 2012 Received: (at control) by debbugs.gnu.org; 7 Jan 2012 04:33:42 +0000 Received: from localhost ([127.0.0.1]:47469 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RjNyQ-0002dY-FR for submit@debbugs.gnu.org; Fri, 06 Jan 2012 23:33:42 -0500 Received: from hermes.netfonds.no ([80.91.224.195]:48548) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RjNyO-0002dK-Lz for control@debbugs.gnu.org; Fri, 06 Jan 2012 23:33:41 -0500 Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58] helo=stories.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1RjNyJ-00022S-2m for control@debbugs.gnu.org; Sat, 07 Jan 2012 05:33:35 +0100 Date: Sat, 07 Jan 2012 05:33:34 +0100 Message-Id: To: control@debbugs.gnu.org From: Lars Magne Ingebrigtsen Subject: control message for bug #5372 X-MailScanner-ID: 1RjNyJ-00022S-2m X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1326515615.15558@sZgvREWGRCrh3348GTiymw X-Spam-Status: No X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) close 5372 From unknown Sat Sep 06 00:11:36 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 04 Feb 2012 12:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator