From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Gemini Lasswell Newsgroups: gmane.emacs.devel Subject: Re: User interaction from multiple threads Date: Fri, 31 Aug 2018 14:37:44 -0700 Message-ID: <87wos6usif.fsf@runbox.com> References: <838t59j821.fsf@gnu.org> <87lg92q7ih.fsf@runbox.com> <87bm9xqg46.fsf@runbox.com> <838t51dl10.fsf@gnu.org> <87efehqdlv.fsf@gmail.com> <3c3e954d-65fc-58e6-9165-1c775ead69a2@orcon.net.nz> <87bm9kr3ad.fsf@gmail.com> <83y3co0zmb.fsf@gnu.org> <875zzrrg5b.fsf@gmail.com> <83k1o721qm.fsf@gnu.org> <874lfbr4oy.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1535752475 11771 195.159.176.226 (31 Aug 2018 21:54:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 31 Aug 2018 21:54:35 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux) Cc: psainty@orcon.net.nz, Eli Zaretskii , emacs-devel@gnu.org To: John Shahid Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 31 23:54:31 2018 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 1fvrN6-0002uH-A7 for ged-emacs-devel@m.gmane.org; Fri, 31 Aug 2018 23:54:28 +0200 Original-Received: from localhost ([::1]:58577 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fvrPC-0004NL-Ol for ged-emacs-devel@m.gmane.org; Fri, 31 Aug 2018 17:56:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48060) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fvrMB-0002XM-GH for emacs-devel@gnu.org; Fri, 31 Aug 2018 17:53:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fvr75-0004Pn-VX for emacs-devel@gnu.org; Fri, 31 Aug 2018 17:37:59 -0400 Original-Received: from aibo.runbox.com ([91.220.196.211]:58420) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fvr75-0004P5-Ks; Fri, 31 Aug 2018 17:37:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.com; s=rbselector1; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From; bh=Efd9gDVrao1WgT5C3e/EaRo9xgFromhs1HJKeGXF+4E=; b=NNtnAabMT3/GcsihXgdp04Q1a6 MVoapm4e1hRPukjdYgb+NXTojZ2zhcHzk8FeRDWlmwM7qbP06yuEdpS290PynvnqjhudtEuOC81TT lAmPq/KOODrz9kzq4Thd2CzPJ8YD4StFUh18SLtuRKPP2lyxQnxPqa1u3ZZViXX36V2d/Y3LgO/TF TqbUvkhsIP5gNlyDpAGltGpF+yY5omKm/oBLP6szxPeyATP99O163dlcB9JOwy9pWsPs44ig+BPlx xl00Qvvak5DAZ24/qVzTQyYhLrgEPWFDnbzbsfZw3Qn1icqJo3+u4Wgd88zzi3uSyJPBkTClmGPj4 pG7WIgDw==; Original-Received: from [10.9.9.210] (helo=mailfront10.runbox.com) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1fvr73-0003AD-0l; Fri, 31 Aug 2018 23:37:53 +0200 Original-Received: by mailfront10.runbox.com with esmtpsa (uid:179284 ) (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1fvr6x-0004Kg-8C; Fri, 31 Aug 2018 23:37:47 +0200 In-Reply-To: <874lfbr4oy.fsf@gmail.com> (John Shahid's message of "Thu, 30 Aug 2018 16:15:57 -0400") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 91.220.196.211 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:229150 Archived-At: John Shahid writes: >> No, it is not. There are also various other parts of the global state >> that should be specific to a thread, like the list of condition-case >> handlers; see the members of 'struct thread_state' as it is defined >> now, for more examples. > > I am not sure I totally understand the impact of every field in that > struct has on my proposal. I'm still developing my understanding of all this as well, and one important point that wasn't obvious to me at first is that each thread has its own special binding stack. This is the m_specpdl field of thread_state, and is described a bit in lisp.h. In addition to unwind-protects and the Lisp backtrace, it keeps track of dynamically-bound variables, the values of which are local to each thread. The implication of this for the scenario of having a non-main thread ask the main thread to prompt on its behalf is that not just buffer-local variables but other global variables, and anything cl-letf can bind (including function definitions) would have to be communicated between the threads.