From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Make computational threads leave user interface usable Date: Fri, 03 Nov 2017 11:50:46 -0400 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1509724330 19971 195.159.176.226 (3 Nov 2017 15:52:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 3 Nov 2017 15:52:10 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 03 16:52:05 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eAeGA-0004Dp-Fx for ged-emacs-devel@m.gmane.org; Fri, 03 Nov 2017 16:51:54 +0100 Original-Received: from localhost ([::1]:37269 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eAeGH-0007nS-RU for ged-emacs-devel@m.gmane.org; Fri, 03 Nov 2017 11:52:01 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42402) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eAeFR-0007n5-Nl for emacs-devel@gnu.org; Fri, 03 Nov 2017 11:51:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eAeFL-0003oc-NQ for emacs-devel@gnu.org; Fri, 03 Nov 2017 11:51:09 -0400 Original-Received: from [195.159.176.226] (port=60888 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eAeFL-0003n1-Fr for emacs-devel@gnu.org; Fri, 03 Nov 2017 11:51:03 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1eAeF8-0008OT-I6 for emacs-devel@gnu.org; Fri, 03 Nov 2017 16:50:50 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 27 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:sbcwlijB3NRDk7eEAc9CK9BG1RQ= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:219887 Archived-At: > What if this auto-yield is made optional? The problem is that the megabytes of C and Lisp code out there all assume that there's only a single thread running. This assumption is so strong that we don't even really provide the synchronization primitives necessary to make real concurrent programming usable (e.g. locks, transactions, ...). So such an option would be similar to a "please corrupt my Emacs state in random ways" option. As you've seen context switches are currently very expensive (they undo all the dynamic-bindings of the source thread and reinstall the dynamic-bindings of the destination thread). It's probably a good idea to start thinking about how to add real concurrency to Emacs, but it needs to start by looking at how we can make sure the concurrent threads only share read-only data (plus some extra shared state properly protected via some transactional system, or maybe just no shared state but some messaging mechanism instead). That requires a serious design effort on the Elisp side, with a good understanding of the current C code, plus some deep changes at the C level. Stefan