From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: What's the problem? Date: Wed, 10 Dec 2003 01:45:05 +0200 Organization: JURTA Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87iskpbloe.fsf@mail.jurta.org> References: <87oevbes4h.fsf@emacswiki.org> <20031117040607.C6C5D79B72@server2.messagingengine.com> <87ekvpx18d.fsf@emptyhost.emptydomain.de> <4nad6cikxy.fsf@holmes.bwh.harvard.edu> <4nllpt3hr3.fsf@lockgroove.bwh.harvard.edu> <5bad69zd43.fsf@lister.roxen.com> <4noeuon378.fsf@lockgroove.bwh.harvard.edu> <4ny8tsgxy6.fsf@lockgroove.bwh.harvard.edu> <4nhe0ggv0u.fsf@lockgroove.bwh.harvard.edu> <4nk75bwjaf.fsf@lockgroove.bwh.harvard.edu> <4nsmjv8d32.fsf@collins.bwh.harvard.edu> Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1ATrm0-0002VQ-00 for ; Wed, 10 Dec 2003 01:00:12 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1ATrm0-0003Nf-00 for ; Wed, 10 Dec 2003 01:00:12 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1ATsgm-0004a4-OL for emacs-devel@quimby.gnus.org; Tue, 09 Dec 2003 19:58:52 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1ATsdO-0001tv-Uq for emacs-devel@gnu.org; Tue, 09 Dec 2003 19:55:23 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1ATscm-0001B3-4y for emacs-devel@gnu.org; Tue, 09 Dec 2003 19:55:15 -0500 Original-Received: from [64.246.52.22] (helo=ns5.tangramltd.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1ATsbs-0008GE-39 for emacs-devel@gnu.org; Tue, 09 Dec 2003 19:53:48 -0500 Original-Received: from 80-235-38-138-dsl.mus.estpak.ee ([80.235.38.138] helo=mail.jurta.org) by ns5.tangramltd.com with esmtp (Exim 4.20) id 1ATreB-0004P4-FE; Wed, 10 Dec 2003 01:52:07 +0200 Original-To: Simon Josefsson In-Reply-To: (Simon Josefsson's message of "Mon, 08 Dec 2003 20:57:56 +0100") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns5.tangramltd.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jurta.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:18590 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18590 Simon Josefsson writes: > Luke Gorrie writes: >> People are writing concurrent programs in Elisp today. Most programs >> interacting with external processes and sockets do so without blocking >> Emacs. Can't we all just do the same? > > No. > > I believe several examples have been given already, but the most > prominent I notice frequently is generating summary buffers in Gnus. > This is CPU bound. Most of the time is NOT spent waiting from network > IO, even for 64kbps users, if you profile large groups. It is spent > traversing internal data structures, sorting and filtering the > headers. If this is done asynchronously, it would still lock up > Emacs. Many CPU bound tasks can be improved by memoizing computation results. Since most cited here example is generating summary buffers in Gnus, I want to note that this particular problem can be solved by storing computed thread trees in files similar to `.marks' and `.overview'. To keep track of computed results input parameters should be stored along with computed data. > Another example is getting new mail in Gnus. This is probably more > network bound than CPU bound, but doing it asynchronously would still > lock up Emacs completely for many seconds, which is unacceptable. If > you use Gnus as a offline reader, getting new mail may take minutes. Many tasks can be performed by external processes. Getting new mail shouldn't lock up Emacs when done by an external program like movemail. > The most interesting examples doesn't exist, though, because people > have simply not implemented some ideas because of a lack of > multi-threaded support in Emacs. If developers realized you could > have a background thread in Emacs doing various calculations and > giving the user feedback or interaction opportunities once in a while, > I'm sure we'd see many interesting add-on packages. (SETI@Emacs?) I believe too that implementing multi-threaded support in Emacs will create more possibilities for new and existing Emacs packages, for instance, for such computation-intensive tasks as rendering markup languages and for creating a better web browser in Emacs. -- http://www.jurta.org/emacs/