From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Can we go GTK-only? Date: Sun, 30 Oct 2016 15:49:02 -0700 Message-ID: <11E61536-1345-4B81-999D-2E17F8B14C62@dancol.org> References: <24db2975-17ca-ad01-20c8-df12071fa89a@dancol.org> <4615E73A-19E2-4B79-9889-D3FA686DDDE6@raeburn.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1477867784 11826 195.159.176.226 (30 Oct 2016 22:49:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 30 Oct 2016 22:49:44 +0000 (UTC) User-Agent: K-9 Mail for Android Cc: emacs-devel@gnu.org To: Stefan Monnier , Ken Raeburn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 30 23:49:40 2016 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 1c0yup-0000jC-Us for ged-emacs-devel@m.gmane.org; Sun, 30 Oct 2016 23:49:24 +0100 Original-Received: from localhost ([::1]:60419 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c0yus-0000Wc-Md for ged-emacs-devel@m.gmane.org; Sun, 30 Oct 2016 18:49:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38948) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c0yum-0000WT-GF for emacs-devel@gnu.org; Sun, 30 Oct 2016 18:49:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c0yui-00012M-Hf for emacs-devel@gnu.org; Sun, 30 Oct 2016 18:49:20 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:59930) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c0yui-000121-8L for emacs-devel@gnu.org; Sun, 30 Oct 2016 18:49:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Message-ID:CC:To:Date:From:Subject:Content-Type:Content-Transfer-Encoding:MIME-Version:References:In-Reply-To; bh=LUcybDrHZcWLhBxA9jAkS5bsoYpFyQxbXtZgrVav3x4=; b=pGcVVqGTqRQJKB+K1VJuXxHPzVC3tSNcjQDlGAgWQ29ZTIS+k9JCNUN9wCryAdJzxJUMJuMufPqdaJvbVF2tJLeakW4gM1FrBJH8YnV+ja7yBJSMfFwnMWAZpt6V20HGxWobVRNd2FTPqKdZFL+E7HFTHCDlaqRaySQRuKmTbuXk5CZkjkoKud5kAiVn1zSLwskU2swytfN0chuskk7vDkwYhHFQqwaOP7cl+YZO7il1S01zyyl7zsnyRV10KF/7rayhtRPZVjXjujIqy84VAzaFjZr6zx2q6PE95t6K9m6hJ2s5JsC9Q5GvmUvzIKz+BjEaH0yD86UU0DCQT4CZnQ==; Original-Received: from mobile-166-176-184-143.mycingular.net ([166.176.184.143] helo=[10.83.150.148]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1c0yue-0004Tm-I8; Sun, 30 Oct 2016 15:49:12 -0700 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:209001 Archived-At: On October 30, 2016 2:42:18 PM PDT, Stefan Monnier wrote: >> I wonder if we should let them run their event loops, in their own >threads, >> and separate that from the non-GUI events like subprocesses and >timers, and >> from Lisp evaluation, as much as possible. For that matter, some of >the >> subprocess handling could probably use helper threads, like for TLS >> encryption and decryption work. > >Ideally, yes, I definitely think we should split the Emacs process into >various threads: >- some threads for the GUI. >- one thread for the Elisp engine (which receives events from the GUI > threads among others). > >So the GUI thread would handle the expose events, read-locking the >matrices, while the redisplay would run in another thread, >write-locking >those same matrices. Agreed. That's basically how IntelliJ works too. We can do even better too: there's no reason these parts need to run in the same process it even the same machine. But this scheme won't really eliminate the coupling between redisplay and lisp though, since the former calls into the latter. The redisplay thread has to block waiting on lisp anyway. Anyway, I strongly encourage you to look at the React Native rendering model. It's the most elegant way I've seen of constructing GUIs in general. The key insight there is that we shouldn't have redisplay *lock* the display matrix and render it. The lisp universe should send a *copy* of the matrix set, then go about its business. This way, redisplay can go display that copy and everything is decoupled. You turn the system into an Erlang like message passing environment. .