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: Tue, 04 Jul 2023 17:29:07 +0000 Message-ID: <87v8ezpov0.fsf@localhost> References: <871qhnr4ty.fsf@localhost> <83v8ezk3cj.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24164"; 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 Tue Jul 04 19:29:41 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 1qGjqP-00063H-CM for ged-emacs-devel@m.gmane-mx.org; Tue, 04 Jul 2023 19:29:41 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qGjq3-0003iU-Ve; Tue, 04 Jul 2023 13:29:21 -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 1qGjpy-0003hu-9C for emacs-devel@gnu.org; Tue, 04 Jul 2023 13:29:14 -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 1qGjpw-0005K8-4W for emacs-devel@gnu.org; Tue, 04 Jul 2023 13:29:14 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 4665B240027 for ; Tue, 4 Jul 2023 19:29:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1688491749; bh=M05L8kmbnzAeA9KOchiknHstvNb1Y46+HATz7jbDoXE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:From; b=PEoXFoLqukTayF6HUM12YRRmPCb+QgohTka3lvrxgZeUCq7edACZrWNoCjd1w9HJv 5CQKYLbabwEXichi3DiIpS7xIcKF1gLc0/FVj4jVc+xA8+GM5in6PJcMPqWmVttJXn icU+3ip4aOyI8ME/QCQ0U/BVSE9KlRLL5yD966BrbzuVeasTOe18i1X8hL02YnYMRY /w2ZsAYUDN7Fjb7f6RLXESAXuzMMhFarbP/wQRhZ0E6CCiK0JKkvQ/THSLHnv00IaE S2/rKX+XV1mR7atA6izaiN2xByiRylsZp4lcpJMkS+JDCybDFjXN/LlqpCVOpL1OYL YwC3TdgJFWh/g== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4QwVC84wfjz6tvw; Tue, 4 Jul 2023 19:29:08 +0200 (CEST) In-Reply-To: <83v8ezk3cj.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:307436 Archived-At: Eli Zaretskii writes: >> 1. Limit the async process memory to a small lexical subset of symbols >> (within a function). >>=20 >> 2. Every time the async process needs to read/write a symbol slot >> outside its lexical scope, query the main Emacs process. > > If it queries the main process, it will have to wait when the main > process is busy. So this is not really asynchronous. Sure. But not every asynchronous process would need to query the main process frequently. As a dumb example: (defun test/F (n) "Factorial" (declare (pure t)) (let ((mult 1)) (dotimes (i n) (setq mult (* mult i))) mult)) This function, if called asynchronously, will need to query input (N) and later return the output. The main loop will not require any interactions and will take most of the CPU time. If the async process have a separate garbage collector, such process will free the main Emacs process from allocating all the memory for i and mult values at each loop iteration. >> More concretely, is it possible to copy internal Elisp object >> representations between Emacs processes and arrange mutability to query >> the right Emacs process that "owns" the object? > > This is software: anything's possible ;-). But Someone=E2=84=A2 needs to > write the code, like marshalling and unmarshalling of such objects > between two processes. (We do something like that when we write then > load the pdumper file.) There's more than one way of skinning this > particular cat. As the first step, I wanted to hear if there is any blocker that prevents memcpy between processes without going through print/read. >> The inter-process communication does not have to be asynchronous, but >> may work similar to the existing thread implementation. > > I wouldn't recommend designing anything by the example of Lisp > threads. 'Nough said. IMHO, the main problem with threads is that they cannot be interrupted or fire too frequently. In the proposed idea, this will not be such a big deal - inter-process communication is a known bottleneck for any asynchronous code and should be avoided anyway. --=20 Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at