From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: Concurrency, again Date: Tue, 18 Oct 2016 06:08:49 -0400 Message-ID: <31A629C9-7C3B-4B5D-A5B5-38F556C4E064@raeburn.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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1476785412 19841 195.159.176.226 (18 Oct 2016 10:10:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 18 Oct 2016 10:10:12 +0000 (UTC) Cc: tom@tromey.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 18 12:10:07 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 1bwRLD-0002dY-O8 for ged-emacs-devel@m.gmane.org; Tue, 18 Oct 2016 12:09:51 +0200 Original-Received: from localhost ([::1]:40035 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwRLF-0005Ax-S2 for ged-emacs-devel@m.gmane.org; Tue, 18 Oct 2016 06:09:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60457) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwRKK-00059N-96 for emacs-devel@gnu.org; Tue, 18 Oct 2016 06:08:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwRKG-0005yB-2X for emacs-devel@gnu.org; Tue, 18 Oct 2016 06:08:56 -0400 Original-Received: from mail-qt0-x231.google.com ([2607:f8b0:400d:c0d::231]:33956) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bwRKF-0005xp-RB for emacs-devel@gnu.org; Tue, 18 Oct 2016 06:08:51 -0400 Original-Received: by mail-qt0-x231.google.com with SMTP id q7so148960579qtq.1 for ; Tue, 18 Oct 2016 03:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raeburn-org.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OL+6Yde0MxxjZdliYVuPs0IvRMBPwEm6+p/Vqhak7mI=; b=SqD1s7Uhw+lhTRY0sX73pKP1XdNtHOBADgQmf83mwCf0TzKfnaE2+oPMZItsy3Htoo DzXAhwAll1KZa5Sa3yvo416ly69UToa9zbRq9uGnYIHBhixT0EzFXzI16Mj2rOPZyl8G OvTqLJEpWXX9DbBzYlVkJTuG9cdnxwvOVBeThR0J8RSuXhIuSgacjOKOj3a2c8L76QrL 5AAk47gJqBGcE9aQ/QQTwDnhjx7aUjt+XYBD6I+aJokVnTuIgW5uRx9zctF5ih1sZ/7d BAeGEJLNz3vS/K0tIWDEuT6guoH6lc2cfeTudi67uwopPpWZA1inX+3FmV/VgYNCK5Z5 qBhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OL+6Yde0MxxjZdliYVuPs0IvRMBPwEm6+p/Vqhak7mI=; b=QfXJr1F9b0YLpVb4Fe1Vbu1aBdiw6d7NtRh6PWejlexvbrRDVFT8CSowiSlNyGo7f4 ND/SzYSerXoU2HEvcLoKgvh5+S57x/IRwHJtfdZ/H8zN2n4y2QDaqi84kdy4wtZ1r8QN Re1jE5s0u9H6Mo4P9xITKhWWc1ECE1aS3iCfI6o5NusrzyBuBa0NzkedOx0nGTicEoCw bQtVn/Pv8X1BiVu1JSfgKusGCHF+FWwx4W/Iwr/SqML/227qJ7nqzJgdCZ1noh968chS Sb3nt1IhLGgEGxp1ciUA9W07ZF5RAcMuf/fNyx51xxqkzLHDXomCJAA0It0SQ1drPPLr KNGg== X-Gm-Message-State: AA6/9RkmZWZXAK8c2+1tCiBivqcR8UW8VI/IiOr1+X4b9B6hmMLit1eZ0t+X1vO0UrUBIQ== X-Received: by 10.200.47.198 with SMTP id m6mr1868347qta.5.1476785331244; Tue, 18 Oct 2016 03:08:51 -0700 (PDT) Original-Received: from [192.168.23.52] (c-50-138-183-136.hsd1.ma.comcast.net. [50.138.183.136]) by smtp.gmail.com with ESMTPSA id d9sm13048036qkj.25.2016.10.18.03.08.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 18 Oct 2016 03:08:50 -0700 (PDT) In-Reply-To: <8337juxb8h.fsf@gnu.org> X-Mailer: Apple Mail (2.3124) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400d:c0d::231 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:208401 Archived-At: > On Oct 18, 2016, at 05:22, Eli Zaretskii wrote: >=20 >> From: Ken Raeburn >> Date: Tue, 18 Oct 2016 03:58:04 -0400 >> Cc: emacs-devel@gnu.org >>=20 >> I collected some notes from those past discussions, though it was = often unclear whether there was consensus on certain things being needed = or whether they were just ideas being kicked around. My list, aside = from the note to go back and review the discussions again :-) =E2=80=A6 >>=20 >> * collapse systhread and thread, adding w32threads.c to emulate the = pthread interface >=20 > This can be done later, it's not a critical issue, IMO. >=20 >> * header inclusion order requirement is weird; can generating one big = header help? >=20 > I'm not sure I understand what inclusion order is being alluded to > here. Can you elaborate? I think it=E2=80=99s 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, =E2=80=9CWe now have an unfortunate situation whereby lisp.h = cannot be included before some of the other headers, due to this.=E2=80=9D= >=20 >> * field names and faking globals with macros: maybe change m_ prefix, = maybe add BVAR-like macro >=20 > Again, not critical. >> * one thread per terminal? >=20 > Why? >=20 >> * file notifications and such shouldn=E2=80=99t go through same queue = as keyboard events >=20 > Why? Stefan=E2=80=99s message: = http://lists.gnu.org/archive/html/emacs-devel/2013-08/msg00755.html >=20 >> * interaction of SIGCHLD handling and threads? >=20 > 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=E2=80=A6. >=20 >> * handle errors in lower-level routines like sys_cond_init >> * ns_select needs fixing >>=20 >> There are also uses of jmp_buf in places that should be examined = carefully, like stack overflow handling, keyboard.c:getcjmp, and image = handling code. >=20 > I'd say, insert appropriate FIXME comments where these issues pop up, > and leave this for later, unless the solution is already known. It=E2=80=99s easy enough to disable stack overflow checking when = enabling thread support. If only one thread is allowed into the image = processing code at a time (i.e., don=E2=80=99t release the global lock = for that code) then that=E2=80=99s probably fine for now, and there=E2=80=99= s probably other state there that different threads shouldn=E2=80=99t be = mucking around with in parallel. The keyboard.c one is the only one = I=E2=80=99m a bit concerned about, in part because I haven=E2=80=99t = looked at it.=