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: User interaction from multiple threads Date: Thu, 30 Aug 2018 20:38:57 +0300 Message-ID: <83k1o721qm.fsf@gnu.org> 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> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1535650639 23645 195.159.176.226 (30 Aug 2018 17:37:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 30 Aug 2018 17:37:19 +0000 (UTC) Cc: psainty@orcon.net.nz, gazally@runbox.com, emacs-devel@gnu.org To: John Shahid Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 30 19:37:15 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 1fvQsc-000621-Iv for ged-emacs-devel@m.gmane.org; Thu, 30 Aug 2018 19:37:14 +0200 Original-Received: from localhost ([::1]:50151 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fvQui-00076j-KS for ged-emacs-devel@m.gmane.org; Thu, 30 Aug 2018 13:39:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60923) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fvQuc-00076d-5k for emacs-devel@gnu.org; Thu, 30 Aug 2018 13:39:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fvQuZ-0001vS-Cp for emacs-devel@gnu.org; Thu, 30 Aug 2018 13:39:18 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:52692) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fvQuY-0001vI-02; Thu, 30 Aug 2018 13:39:14 -0400 Original-Received: from [176.228.60.248] (port=2383 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fvQuW-0005vo-Ju; Thu, 30 Aug 2018 13:39:13 -0400 In-reply-to: <875zzrrg5b.fsf@gmail.com> (message from John Shahid on Thu, 30 Aug 2018 12:08:32 -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:229112 Archived-At: > From: John Shahid > Cc: psainty@orcon.net.nz, gazally@runbox.com, emacs-devel@gnu.org > Date: Thu, 30 Aug 2018 12:08:32 -0400 > > > I'm afraid there's too much to encapsulate. E.g., every buffer-local > > variable in every buffer to be used by the thread will need to be > > encapsulated; and how will the main thread know in advance all that? > > Why do we need buffer local variables for all the buffers ? Not all the buffers, only those which the thread function will make current at some point. Surely, you've seen and written code that switches buffers as part of doing whatever it needs. > Isn't the current buffer during the prompt the only relevant buffer. 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. > My idea, is that each thread is started with a pipe which is used to > interact with the main thread when it needs to prompt the user. If you mean literally a pipe, then does this mean you suggest that Emacs forks itself and runs each thread in a separate process, talking via pipes with other processes? That's a completely different architecture from what we have now, and it wasn't my intent to discuss such a complete rewrite of the concurrency code. If this is not what you mean, please clarify what you mean by "pipe" in this context. > The child thread write the lambda that needs to run on the main > thread then wait for main thread response using > `accept-process-output'. The main thread handles the request in the > process filter displaying the prompt and writing the result back to > the pipe. Since the child and main thread are sharing the same > memory, the communication can simply be the symbol name that holds > the closure and the response, respectively. We already have the async package written by John Wiegley; it sounds like you are describing the idea which he already implemented. The limitation of this is that you need to communicate to much of a state to the subordinate Emacs, and some stuff is very hard, sometimes impossible, to share this way. In any case, let's stay in the framework of the current basic design of how threads work in Emacs. Thanks.