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: Concurrency, again Date: Tue, 18 Oct 2016 13:41:36 +0300 Message-ID: <83wph6vt0f.fsf@gnu.org> References: <87wq97i78i.fsf@earlgrey.lan> <86k2dk77w6.fsf@molnjunk.nocrew.org> <9D64B8EA-DB52-413D-AE6A-264416C391F3@iotcl.com> <83int1g0s5.fsf@gnu.org> <83twckekqq.fsf@gnu.org> <874m4aic0g.fsf@tromey.com> <7D150317-7A01-464D-8352-942631A3116B@raeburn.org> <8337juxb8h.fsf@gnu.org> <31A629C9-7C3B-4B5D-A5B5-38F556C4E064@raeburn.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 1476787560 10796 195.159.176.226 (18 Oct 2016 10:46:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 18 Oct 2016 10:46:00 +0000 (UTC) Cc: tom@tromey.com, emacs-devel@gnu.org To: Ken Raeburn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 18 12:45:56 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 1bwRu1-0001WW-K0 for ged-emacs-devel@m.gmane.org; Tue, 18 Oct 2016 12:45:49 +0200 Original-Received: from localhost ([::1]:40217 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwRu3-0008Sd-N6 for ged-emacs-devel@m.gmane.org; Tue, 18 Oct 2016 06:45:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38110) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwRqJ-0005y5-2Q for emacs-devel@gnu.org; Tue, 18 Oct 2016 06:42:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwRqF-0008UP-5Z for emacs-devel@gnu.org; Tue, 18 Oct 2016 06:41:59 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60964) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwRqF-0008UG-1x; Tue, 18 Oct 2016 06:41:55 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4725 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bwRqE-0005j1-2c; Tue, 18 Oct 2016 06:41:54 -0400 In-reply-to: <31A629C9-7C3B-4B5D-A5B5-38F556C4E064@raeburn.org> (message from Ken Raeburn on Tue, 18 Oct 2016 06:08:49 -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:208402 Archived-At: > From: Ken Raeburn > Date: Tue, 18 Oct 2016 06:08:49 -0400 > Cc: tom@tromey.com, > emacs-devel@gnu.org > > >> * header inclusion order requirement is weird; can generating one big header help? > > > > I'm not sure I understand what inclusion order is being alluded to > > here. Can you elaborate? > > I think it’s the ordering and recursive inclusion involving thread.h relative to the other headers. For example lisp.h includes thread.h which includes sysselect.h which includes lisp.h; thread.h uses struct vectorlike_header, so it has to be included in lisp.h after that structure is defined but before struct thread_state gets used; thread.h also includes regex.h which includes lisp.h. You commented at one point, “We now have an unfortunate situation whereby lisp.h cannot be included before some of the other headers, due to this.” This could be solved by moving parts of thread.h into lisp.h, with the appropriate #ifdef guards. I think Lisp objects should be in lisp.h anyway, even if they are optional; anything else is confusing. > >> * one thread per terminal? > > > > Why? > > > >> * file notifications and such shouldn’t go through same queue as keyboard events > > > > Why? > > Stefan’s message: http://lists.gnu.org/archive/html/emacs-devel/2013-08/msg00755.html I don't see that as a critical problem, perhaps because we don't yet realize how serious it can be. The whole purpose of trying to merge the concurrency branch is to collect practical experience as to what should and shouldn't be in this kind of Emacs feature. So I'd tend to let this be, until we find out we can't, and why. > >> * interaction of SIGCHLD handling and threads? > > > > Details? > > Your message http://lists.gnu.org/archive/html/emacs-devel/2013-08/msg00738.html raised questions. If they were ever satisfactorily answered, I overlooked it when putting together my notes…. That should be easy: since a subprocess is locked to a single thread, SIGCHLD should be delivered to that thread. If we don't have that already, we should add that, it doesn't sound hard, given the infrastructure we already have (deliver_thread_signal etc.). > It’s easy enough to disable stack overflow checking when enabling thread support. Or add some simple code in the stack overflow handler to check if we are in the main thread, and if not, punt (i.e. crash). > If only one thread is allowed into the image processing code at a time (i.e., don’t release the global lock for that code) then that’s probably fine for now, and there’s probably other state there that different threads shouldn’t be mucking around with in parallel. Redisplay runs in the main thread anyway, right? If so, there's no problem. > The keyboard.c one is the only one I’m a bit concerned about, in part because I haven’t looked at it. What part(s) of keyboard.c, exactly? Thanks.