From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: multi-threaded Emacs Date: Fri, 05 Dec 2008 10:22:15 -0600 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <863ah2mw20.fsf@lifelogs.com> References: <87abbiody1.fsf@master.homenet> <877i6l5d8s.fsf@master.homenet> <874p1npvtj.fsf@master.homenet> <87ej0qci8g.fsf@master.homenet> <87y6yxm7xr.fsf@master.homenet> <87oczroysm.fsf@master.homenet> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1228494211 19740 80.91.229.12 (5 Dec 2008 16:23:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Dec 2008 16:23:31 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 05 17:24:35 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1L8dTd-0000oI-S5 for ged-emacs-devel@m.gmane.org; Fri, 05 Dec 2008 17:24:26 +0100 Original-Received: from localhost ([127.0.0.1]:48728 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L8dST-00020G-6E for ged-emacs-devel@m.gmane.org; Fri, 05 Dec 2008 11:23:13 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L8dSM-0001wZ-Nz for emacs-devel@gnu.org; Fri, 05 Dec 2008 11:23:06 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L8dSK-0001sC-An for emacs-devel@gnu.org; Fri, 05 Dec 2008 11:23:06 -0500 Original-Received: from [199.232.76.173] (port=38521 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L8dSJ-0001rT-SU for emacs-devel@gnu.org; Fri, 05 Dec 2008 11:23:03 -0500 Original-Received: from main.gmane.org ([80.91.229.2]:54027 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1L8dSJ-0002xk-JF for emacs-devel@gnu.org; Fri, 05 Dec 2008 11:23:03 -0500 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1L8dSF-0002o0-Tf for emacs-devel@gnu.org; Fri, 05 Dec 2008 16:22:59 +0000 Original-Received: from 38.98.147.130 ([38.98.147.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 05 Dec 2008 16:22:59 +0000 Original-Received: from tzz by 38.98.147.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 05 Dec 2008 16:22:59 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 35 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 38.98.147.130 X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (gnu/linux) Cancel-Lock: sha1:eBjdBa1Q/KceFyiirw98lRBmz8E= X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:106615 Archived-At: On Fri, 05 Dec 2008 12:02:19 +0100 Helmut Eller wrote: HE> I'm wondering what the exact problem with Gnus is. HE> Certainly, downloading the next article takes a bit of time but threads HE> wont make the download any faster. Is there something the user wants to HE> do while waiting for the next article? Even assuming all server interactions can be backgrounded (they can't AFAIK because of their current design, interacting with the global data all over the place), one place that's slow is article splitting. You fetch an article, then run some rules (e.g. spam filters and registry searches) to decide where it will go. This can be 90% parallelized, I would guess. Reading mail normally has never been so slow that I wished it could be done in the background. Saving the newsrc file is sometimes slow, so backgrounding it would be nice. Of course, you don't want to garble that data so it's important to do it right. The Gnus registry should be asynchronous for: - tracking article move/delete/copy/spool operations - saving the registry file - interacting with spam.el spam.el should be asynchronous for: - running a spam backend on an article - determining the spam score of an article - telling the registry the results of spam processing Ted