From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/78652 Path: news.gmane.org!not-for-mail From: Antoine Levitt Newsgroups: gmane.emacs.gnus.general Subject: Re: Asynchroneous image retrieval in HTML rendering Date: Mon, 02 May 2011 09:52:17 +0200 Message-ID: <87liyp35fy.fsf@gmail.com> References: <87bozwfw84.fsf@gmail.com> <87r58ll8jm.fsf@gmail.com> <87liys4x04.fsf@gmail.com> <87tydewilm.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1304323255 11294 80.91.229.12 (2 May 2011 08:00:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 2 May 2011 08:00:55 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M26954@lists.math.uh.edu Mon May 02 10:00:52 2011 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QGo3n-0006YH-Au for ding-account@gmane.org; Mon, 02 May 2011 10:00:51 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1QGo3G-0006Qy-I4; Mon, 02 May 2011 03:00:18 -0500 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1QGo3F-0006Qo-13 for ding@lists.math.uh.edu; Mon, 02 May 2011 03:00:17 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QGo3E-0000sl-C9 for ding@lists.math.uh.edu; Mon, 02 May 2011 03:00:17 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1QGo3C-0007mR-O6 for ding@gnus.org; Mon, 02 May 2011 10:00:14 +0200 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QGo3B-0006EH-NB for ding@gnus.org; Mon, 02 May 2011 10:00:13 +0200 Original-Received: from portable56.ceremade.dauphine.fr ([193.48.71.56]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 May 2011 10:00:13 +0200 Original-Received: from antoine.levitt by portable56.ceremade.dauphine.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 May 2011 10:00:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 35 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: portable56.ceremade.dauphine.fr User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-Spam-Score: -1.0 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:78652 Archived-At: 01/05/11 17:42, Lars Magne Ingebrigtsen > Antoine Levitt writes: > >>> I think the fix here might be to introduce a new variable >>> `url-asynchronous-dns-lookup' (or something), and then have shr bind it >>> to make url.el more asynchronous. The pauses we experience today when >>> trying to do asynchronous URL retrieval aren't acceptable. Especially >>> if a domain is down or semi-down -- reading the articles becomes almost >>> impossible. > > Oopsie. Actually, the image retrieval in Emacs 24 was extremely > synchronous. Due to changes in `open-network-stream', the :nowait flag > was no longer passed on, so all connections were established > synchronously, even if url.el tried to do it asynchronously. > > I've now fixed this and pushed the fix to Emacs 24. That doesn't change much for my test cases, so I guess the DNS lookup is indeed the bottleneck. > >> Why is DNS even synchroneous in the first place? I'd expect >> "asynchroneous" to mean that both DNS lookup and data transfer are >> non-blocking. > > Emacs uses the built-in resolver (from C), and it does it in the main > Emacs thread. So whenever you resolve something in Emacs, *everything* > in Emacs stops. > > I've written the dns.el resolver in Emacs Lisp, but, of course, it's not > as sturdy as the libc one. (And only works on Linux.) A better fix > would be to write a C-level resolver that forks its own thread, does the > resolving, and then does a callback. Damn emacs monothread model ;)