From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Concurrency via isolated process/thread Date: Wed, 05 Jul 2023 12:40:51 +0000 Message-ID: <87mt0a8rak.fsf@localhost> References: <871qhnr4ty.fsf@localhost> <83v8ezk3cj.fsf@gnu.org> <87v8ezpov0.fsf@localhost> <83r0pnk2az.fsf@gnu.org> <87pm57pns8.fsf@localhost> <83pm57k01f.fsf@gnu.org> <87v8ey8uv7.fsf@localhost> <83bkgqk28a.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23162"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jul 05 14:41:49 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qH1pL-0005o1-41 for ged-emacs-devel@m.gmane-mx.org; Wed, 05 Jul 2023 14:41:47 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qH1od-0000na-FC; Wed, 05 Jul 2023 08:41:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qH1oZ-0000my-D9 for emacs-devel@gnu.org; Wed, 05 Jul 2023 08:41:00 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qH1oW-00051Q-ES for emacs-devel@gnu.org; Wed, 05 Jul 2023 08:40:59 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 3E062240028 for ; Wed, 5 Jul 2023 14:40:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1688560854; bh=mccKCL2amViz7eesWeg0PluXJZK/N8d/ZQbgSpAY/4A=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=iodyhb14QpsCshcCp8YsBQ23xFiWJ9sLThxLf+DKL9Agqe7P2hhH+5kQfY7ze8pfT RBfQCfdRiKZircM22U0eVRazSJkqmUHGAhqdqcgeucnUKBXWsies87oC6CVUZBeQyi uAuS7W5duPlyUZYtR3FfXjjX/PhXt+F3o54AJOFdFu6yYlNfcU4SbJ5KN+qehqnvHh gguebQxaYR5S8EsOPnKwxJwMN5v0KMvUbkP0BING0/QyFAKz5wU2kMIwLOB+2UAFNd HXWVP7FTqA2zfkaEd6rCv90K3q1Zj/A43j5tDSeNezBQkIQxBMIMEi1heOgU0FUX8H MeAz3ckMLkxmg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Qwzm53zCyz9rxD; Wed, 5 Jul 2023 14:40:53 +0200 (CEST) In-Reply-To: <83bkgqk28a.fsf@gnu.org> Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:307459 Archived-At: Eli Zaretskii writes: >> It may be dumb (I have no experience with processes in C), but I have >> something like the following in mind: >> >> 1. Main Emacs process has a normal Elisp thread that watches for async >> Emacs process requests. >> 2. Once a request arrives, asking to get/modify main Emacs process data, >> the request is fulfilled synchronously and signaled back by writing >> to memory accessible by the async process. > > That solves part of the problem, maybe (assuming we'd want to allow > shared memory in Emacs). My idea is basically similar to the current schema of interacting between process input/output and Emacs. But using data stream rather than text stream. Shared memory is one way. Or it may be something like sockets. It's just that shared memory will be faster, AFAIU. > ... The other parts -- how to implement async > process requests so that they don't suffer from the same problem, and > how to reference objects outside of the shared memory -- are still > there. I imagine that there will be a special "remote Lisp object" type. 1. Imagine that child Emacs process asks for a value of variable `foo', which is a list (1 2 3 4). 2. The child process requests parent Emacs to put the variable value into shared memory. 3. The parent process creates a new variable storing a link to (1 2 3 4), to prevent (1 . (2 3 4)) cons cell from GC in the parent process - `foo#'. Then, it informs the child process about this variable. 4. The child process creates a new remote Lisp object #. 5. Now consider that child process tries (setcar # value). The `setcar' and other primitives will be modified to query parent process to perform the actual modification to (# . (2 3 4)) 6. Before exiting the child thread, or every time we need to copy remote object, # will be replaced by an actual newly created traditional object. >> If nobody goes far enough to discover those, >> they are probably not the real reason why people do not use Elisp threads. > > I'm saying that it could be the other way around: we don't hear about > those bugs because threads are not used seriously. I feel like this part of the discussion is not contributing to the main topic. At the end, it is not critical if Elisp threads are used to implement the discussed idea. Or timers, or something else. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at