From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Can we go GTK-only? Date: Mon, 31 Oct 2016 17:54:30 +0200 Message-ID: <83bmy0pl8p.fsf@gnu.org> References: <24db2975-17ca-ad01-20c8-df12071fa89a@dancol.org> <4615E73A-19E2-4B79-9889-D3FA686DDDE6@raeburn.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1477932095 12406 195.159.176.226 (31 Oct 2016 16:41:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 31 Oct 2016 16:41:35 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Ken Raeburn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 31 17:41:31 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 1c1FeE-0001Zw-AQ for ged-emacs-devel@m.gmane.org; Mon, 31 Oct 2016 17:41:22 +0100 Original-Received: from localhost ([::1]:36948 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1FeG-0003FJ-TF for ged-emacs-devel@m.gmane.org; Mon, 31 Oct 2016 12:41:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58872) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1Euj-0002Zx-8u for emacs-devel@gnu.org; Mon, 31 Oct 2016 11:54:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c1Euf-0001Kl-Ac for emacs-devel@gnu.org; Mon, 31 Oct 2016 11:54:21 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49454) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1Euf-0001Kh-7S; Mon, 31 Oct 2016 11:54:17 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3132 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c1Eue-0001I6-FJ; Mon, 31 Oct 2016 11:54:16 -0400 In-reply-to: <4615E73A-19E2-4B79-9889-D3FA686DDDE6@raeburn.org> (message from Ken Raeburn on Sun, 30 Oct 2016 10:43:37 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:209025 Archived-At: > From: Ken Raeburn > Date: Sun, 30 Oct 2016 10:43:37 -0400 > Cc: emacs-devel@gnu.org > > 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. Beware of asking for too much, because that would mean a complete redesign, something that I think is impractical. One problem with having too much code in separate threads is that only the main thread can call malloc/free, i.e. you cannot create/destroy objects in other threads. Another problem is calling QUIT: you need to switch to the main thread before you do that, or else you will crash. And there are probably other limitations. The w32 build uses a separate thread for receiving the window-system events, so you might look there for some ideas that won't blow up the basic MVC design of Emacs. In a nutshell, the events received by the w32 input thread are pushed onto a queue which is serviced by an emulation of a socket-read hook, called from keyboard.c, like all the other such hooks. Of course, this doesn't help when the main thread is busy doing something prolonged, because it then doesn't get to processing the input events.