From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.devel Subject: Re: What's the problem? Date: Mon, 08 Dec 2003 20:57:56 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: 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> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1070914290 24043 80.91.224.253 (8 Dec 2003 20:11:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 8 Dec 2003 20:11:30 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Dec 08 21:11:20 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1ATRiy-00053S-00 for ; Mon, 08 Dec 2003 21:11:20 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1ATRix-00088O-00 for ; Mon, 08 Dec 2003 21:11:20 +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 1ATSWs-0002sE-IX for emacs-devel@quimby.gnus.org; Mon, 08 Dec 2003 16:02:54 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1ATSUd-0002c6-0m for emacs-devel@gnu.org; Mon, 08 Dec 2003 16:00:35 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1ATSU4-0002U2-10 for emacs-devel@gnu.org; Mon, 08 Dec 2003 16:00:32 -0500 Original-Received: from [217.13.230.178] (helo=yxa.extundo.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1ATSU3-0002S7-5Y for emacs-devel@gnu.org; Mon, 08 Dec 2003 15:59:59 -0500 Original-Received: from latte (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.10/8.12.10) with ESMTP id hB8JwHAU022562 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 8 Dec 2003 20:58:21 +0100 Original-To: Luke Gorrie Mail-Copies-To: nobody X-Payment: hashcash 1.2 0:031208:luke@bluetail.com:dac2089d95ff606c X-Hashcash: 0:031208:luke@bluetail.com:dac2089d95ff606c X-Payment: hashcash 1.2 0:031208:emacs-devel@gnu.org:882d2d69c5aad9b3 X-Hashcash: 0:031208:emacs-devel@gnu.org:882d2d69c5aad9b3 In-Reply-To: (Luke Gorrie's message of "08 Dec 2003 19:25:35 +0100") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) 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:18566 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18566 Luke Gorrie writes: > Ted Zlatanov writes: > >> I'm convinced, based on the many posts made, that the best way to >> approach multithreading is slowly and incrementally. > > What's the biggest problem that threads are intended to solve? > > Is it that it's too hard or ugly to write concurrent programs in Elisp > today? It is too hard and ugly to write concurrent programs in elisp today, but that is not the only reason. > If so, what are some examples of bad cases that cause users pain and > _really_ can't be rewritten neatly and with happy concurrency > properties in plain old Elisp after some rethinking? > > (Sorry if I have missed definitive examples earlier in the thread!) > > 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. 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. 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?)