From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: "concurrency" branch updated Date: Tue, 3 Nov 2015 04:40:25 -0500 Message-ID: <1B30AC54-4A83-4437-8BA8-B80F4ED6AF1A@raeburn.org> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1446543649 27684 80.91.229.3 (3 Nov 2015 09:40:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Nov 2015 09:40:49 +0000 (UTC) Cc: "emacs-devel@gnu.org discussions" To: John Wiegley Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 03 10:40:43 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZtY52-0007oo-55 for ged-emacs-devel@m.gmane.org; Tue, 03 Nov 2015 10:40:40 +0100 Original-Received: from localhost ([::1]:46666 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZtY51-0001Ss-5G for ged-emacs-devel@m.gmane.org; Tue, 03 Nov 2015 04:40:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42895) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZtY4q-0001Pf-4o for emacs-devel@gnu.org; Tue, 03 Nov 2015 04:40:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZtY4p-0007cf-4R for emacs-devel@gnu.org; Tue, 03 Nov 2015 04:40:28 -0500 Original-Received: from mail-qg0-x232.google.com ([2607:f8b0:400d:c04::232]:36126) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZtY4p-0007ca-0f for emacs-devel@gnu.org; Tue, 03 Nov 2015 04:40:27 -0500 Original-Received: by qgad10 with SMTP id d10so7784855qga.3 for ; Tue, 03 Nov 2015 01:40:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raeburn_org.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rJM1alml68Uo6z8KuGBow18MPk3Zb+qOXInyv+V01ss=; b=RiQCvaysDqFzqD0vos/CYPwZEtMhvey35APEPLABppGwKAMPPc8ywF9IWAE8YeGjNw JUUhwbTJka0db3s+UlFrc7wcbJ6K/eYGeNVpaI4wsT3BipxZ4gav+7UV2xlzf8QHVixc dSlRk3hQEC10WQ7GkQJKHyASOQHGAxPY73Lmtun+4dlMg9AnlwVhhyRyKeuEXIfUrSWV GZPRxJ34/l1sGxwAm6LvizaUHDzew2Gbw9KckPU/EHmONAAO5WUNrRCLFNd7nR3PsEzE BkOvQ5DZ3WTM/pOGDyfWLMUq6dnRT7xwJ4HsHnPRZce2pPUKXJTbDxsVOtNxJIlZgHZb 0tDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=rJM1alml68Uo6z8KuGBow18MPk3Zb+qOXInyv+V01ss=; b=PBhqa7kZCBE3ONOXKx6OROBJhv9ZDD6IpmXDfpcfGzd/ecHiJaPgPOiFU+pEIUaOFc XwF49rnYECIlYBx+2u566ew/kfO+yMPbXJ/ftINXtd53t5DiRfgUoEyVQUWGxxC8sPrK K1Ld48957YTogjh+yRZRAGdNDmUoe64lbLM4c9Z5xY/FLZ3u8NTm9Tu/4eRQ5jvon57v fc0l2a9vmg2TJ50WnMYQLHhlv+afIhdTtly6LQ4EcFRQfDU2i3e7oXv3Nu+9ktC7tdUK 652miVP/eAUJwxqeYJ3GS3DvdLHEt3X01wwFDwkIxyVWVluLALwx2O/XQhITkGcJz/5f Nueg== X-Gm-Message-State: ALoCoQnj/NMg9lCbHbY2yRzt9SJZVwcIRW1XgepV4GTJ/ovGX5+tu7qHBoEWG7QFsu55rKAIpyMY X-Received: by 10.140.42.74 with SMTP id b68mr18145928qga.48.1446543626728; Tue, 03 Nov 2015 01:40:26 -0800 (PST) Original-Received: from [192.168.17.111] (c-66-31-203-101.hsd1.ma.comcast.net. [66.31.203.101]) by smtp.gmail.com with ESMTPSA id z194sm8858794qhz.10.2015.11.03.01.40.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Nov 2015 01:40:26 -0800 (PST) In-Reply-To: X-Mailer: Apple Mail (2.2104) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c04::232 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:193133 Archived-At: > I'm unfamiliar so far with the content of the concurrency branch, what = changes > it makes, and the threading model it proposes. Could you please = summarize the > state of the art for me, so that I know what this branch entails? The email threads that Eli pointed to are the best starting point. I=E2=80= =99m doing some catching up myself; I haven=E2=80=99t worked on this = branch until recently, though I've gotten a basic understanding of some = of it through working on the merge. I=E2=80=99ve got to dig through the = emails from earlier reviews of the code and make some notes on things = not yet done. In addition to some proposed code changes, I=E2=80=99m = sure at a minimum much more testing and bug fixing is needed, some = assessment of the performance, and possibly some utility functions would = be nice to have (e.g., mutex-try-lock, mutex-timed-wait). At some point, we=E2=80=99ll want to demonstrate practical utility; not = a trivial demo program that displays a few messages, and nothing on the = scale of rewriting all of Gnus to be multithreaded, but somewhere in = between. I=E2=80=99m not sure what would be a good example. A version = of generator.el that uses threads instead of the CPS transformation of = everything is a possibility, and it would probably simplify the writing = and compiling of the generators, but it=E2=80=99d probably be more = heavy-weight at run time. Prefetching files=E2=80=99 contents, or = searching already-loaded files, while tags-query-replace waits for the = user to respond to a prompt? Improving fontification somehow? Concurrent execution of Lisp code is a way off, but IMHO a desirable = thing to shoot for, if we want Emacs to get faster as machines go for = multicore rather than faster clocks. Currently, only one thread runs = Lisp at a time, and switching can happen only at certain points (when = explicitly requested, or when select is called), though I think we = should try to expand that set of points. Tom suggested possibly doing = it periodically when we invoke the QUIT macro, which would include = various points in the bytecode interpreter. > Opening a general discussion about concurrency is something I'd like = to do > soon, but not until I better understand what has already taken place. Understood. I think there may also be places where we could use threads = less visible to the Lisp world; TLS and redisplay come to mind. Ken=