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: The event handling thread Date: Thu, 22 Dec 2016 19:37:13 +0200 Message-ID: <837f6r27cm.fsf@gnu.org> References: <8360mj99oe.fsf@gnu.org> <83fulk610j.fsf@gnu.org> <83wpeu37nq.fsf@gnu.org> <831sx12n7f.fsf@gnu.org> Reply-To: Eli Zaretskii 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 1482428272 7873 195.159.176.226 (22 Dec 2016 17:37:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 22 Dec 2016 17:37:52 +0000 (UTC) Cc: emacs-devel@gnu.org To: Elias =?utf-8?Q?M=C3=A5rtenson?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 22 18:37:48 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 1cK7JL-0001Wl-Mi for ged-emacs-devel@m.gmane.org; Thu, 22 Dec 2016 18:37:47 +0100 Original-Received: from localhost ([::1]:35464 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cK7JQ-0005aM-8G for ged-emacs-devel@m.gmane.org; Thu, 22 Dec 2016 12:37:52 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48119) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cK7JJ-0005a1-I6 for emacs-devel@gnu.org; Thu, 22 Dec 2016 12:37:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cK7JG-0000Hq-FM for emacs-devel@gnu.org; Thu, 22 Dec 2016 12:37:45 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38675) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cK7JG-0000Hm-CF; Thu, 22 Dec 2016 12:37:42 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1131 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cK7JF-0001u0-JU; Thu, 22 Dec 2016 12:37:42 -0500 In-reply-to: (message from Elias =?utf-8?Q?M=C3=A5rtenson?= on Thu, 22 Dec 2016 11:12:08 +0800) 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:210738 Archived-At: > From: Elias Mårtenson > Date: Thu, 22 Dec 2016 11:12:08 +0800 > Cc: emacs-devel > > > But that doesn't change the fact that it makes more sense to never allow keyboard input to be > processed by > > anything other than the main thread? > > Why does it make more sense than, say, serialize access to the > minibuffer such that only one thread can access it at a time? > > It would, if the minibuffer was the only place where the keyboard was read. However, isn't this problem wider > than just the minibuffer? It is. But minibuffer input is IMO the most urgent issue to solve, because Emacs interacts with the user like that quite a lot. > In my tests with ‘sit-for’ and threads, I noticed that if multiple threads do ‘sit-for’ at the same time, and a press > a key, then only one of the threads gets released. As you keep generating input, more and more of the threads > exit the call to ‘sit-for’. A central input processing thread would fix this issue too, right? Could you show some code where this can be seen? I'm not sure I understand how exactly this happens. What I saw in my testing is that only the primary thread waits on the keyboard descriptor, but maybe I'm missing something. Perhaps your tests made the primary thread yield, or wait on some synchronization object? > > C-g isn't "normal" keyboard input, is it? > > It depends. It's a bit of both, at least on GUI frames. > > Is this related to the messy event loop in GTK Emacs that people were commenting on in some other thread > recently? It is related to that, and also to how C-g and keyboard input are treated in other configurations we support. AFAIR, TTY, X11, GTK, and w32 -- each one of these has its own slightly different model of handling keyboard input and C-g. Probably NS has yet another one.