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 13:26:54 +0000 Message-ID: <87bkgq8p5t.fsf@localhost> References: <871qhnr4ty.fsf@localhost> <83v8ezk3cj.fsf@gnu.org> <87v8ezpov0.fsf@localhost> <83r0pnk2az.fsf@gnu.org> <87pm57pns8.fsf@localhost> <87lefvp55t.fsf@yahoo.com> <87sfa28ura.fsf@localhost> <87cz16o8vz.fsf@yahoo.com> <87jzve8r4m.fsf@localhost> <871qhmo5nv.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20165"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jul 05 15:27: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 1qH2Xl-000524-0v for ged-emacs-devel@m.gmane-mx.org; Wed, 05 Jul 2023 15:27:41 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qH2XB-0004TS-4p; Wed, 05 Jul 2023 09:27:05 -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 1qH2X9-0004T2-88 for emacs-devel@gnu.org; Wed, 05 Jul 2023 09:27:03 -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 1qH2X5-0000n4-WB for emacs-devel@gnu.org; Wed, 05 Jul 2023 09:27:02 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id DC9AC240028 for ; Wed, 5 Jul 2023 15:26:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1688563617; bh=IAjlFPfOE9EFWvUVbBFQZecktt9vFKKM7kKNRVBRYZw=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=bBxXun1RFsC2eoUcjw50Cl73VwREcMaAEEare8GvNV0zV59jCeWm7mPnmMxluttao i3+kYJU4mEJbSOGclJUwKgoEMFh7/UM46eUtdSg/KTX8GfOY4cSgHLnH4XbrzNxMdR zGE+2u8l7NZ2otUo6oeykV1EqeV5nX2Lx/HUL3ALvRKdQ/i4zNW1p67nMXqbli2IwP vMP1FeE8CgYZZukytAEos6vHl2WYOSMulpESs5WiFRBqVtQKC6BwKVOeYVGmR4cIjd WDH++5/McqXzG5uhY/nfPRhGbaoIHt18k+7Wy4VedsKGgcsgHrcVTLB3xP+yod8UO1 QzX8YGdzx0rEw== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Qx0nF1Xs8z6txc; Wed, 5 Jul 2023 15:26:57 +0200 (CEST) In-Reply-To: <871qhmo5nv.fsf@yahoo.com> 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=unavailable 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:307468 Archived-At: Po Lu writes: > Ihor Radchenko writes: > >> I imagine that the child Emacs will have a very limited obarray. >> If a symbol is not found in that process-local obarray, a query to >> parent Emacs process will be sent to retrieve the symbol slot values. > > How will you retrieve the value of a symbol that does not exist in the > child process? See my other reply. The idea is to create a special Lisp Object type. > And what about the negative performance implications of > contacting another process to retrieve a symbol's value? The object > will have to be copied from the parent, and the parent may also be busy. Yes, such requests will be synchronous and will need to be avoided. Ideally, child process just need to query input at the beginning and transfer the output at the end without communicating with parent process. Any other communication will be costly. > Anyway, we already have sufficient mechanisms for communicating with > subprocesses. I am only aware of text-based communication. Is there anything else? > If Emacs is to take any more advantage of SMP systems, it > must be properly interlocked, with multiple processors sharing the same > memory. This lesson was learned decades ago with another program: > vmunix. AFAIU, one of the big blockers of this is single-threaded GC. Emacs cannot free/allocate memory asynchronously. Or do I miss something? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at