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: Mon, 24 Jul 2023 14:24:32 +0000 Message-ID: <87ila91j6n.fsf@localhost> References: <871qhnr4ty.fsf@localhost> <83ilawhpi6.fsf@gnu.org> <87zg48apwr.fsf@localhost> <83edljg8ub.fsf@gnu.org> <87o7knbxr7.fsf@localhost> <838rbrg4mg.fsf@gnu.org> <87ilavbvdr.fsf@localhost> <834jmffvhy.fsf@gnu.org> <878rbrbmwr.fsf@localhost> <83fs5zecpo.fsf@gnu.org> <87351zbi72.fsf@localhost> <83351yevde.fsf@gnu.org> <87cz12ad2w.fsf@localhost> <83a5w6cwdr.fsf@gnu.org> <87pm518m0g.fsf@localhost> <83o7kl9tyj.fsf@gnu.org> <874jmd89us.fsf@localhost> <878rb53dkj.fsf@localhost> <83edkxsclz.fsf@gnu.org> <87tttt1mzh.fsf@localhost> <83351ds9de.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="28675"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 24 16:25:18 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 1qNwUv-0007Fy-R2 for ged-emacs-devel@m.gmane-mx.org; Mon, 24 Jul 2023 16:25:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qNwU6-0001va-4c; Mon, 24 Jul 2023 10:24:26 -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 1qNwU5-0001vS-3p for emacs-devel@gnu.org; Mon, 24 Jul 2023 10:24:25 -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 1qNwU2-0005MW-NC for emacs-devel@gnu.org; Mon, 24 Jul 2023 10:24:24 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 73A04240028 for ; Mon, 24 Jul 2023 16:24:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1690208660; bh=WfY/NmuRUctvkfv3Mjm6SV/NeQVnMKkqbLWwiUeT9Ag=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=gSbWUzZanc9TMySJOHQ9Qzc74Nt0rvqFDyoHN7REs1j6540lGjGdfEXb6GPSWdLAQ duO0t0kCTgdTzNsmLag/3vqELxv0rEFzUcE1AZ+eydd89RY7g0WLgiqs2TUGqD9ktN n7UVvCvtWInqBDiubCZ24jMmELdQpdjgHxHjfjPXV0ku/wnbuRkPIz+/yG70jVYzII V/ZPnjoAIRBAHikVzR2yCdNtSD3qcFglTctEAcrFeVIPkMQ2Xy2SPyxWBd6+yIC+TM oIPl+g9b6fMCI8ULLtzCWRPHTOTYW5Us4xxolkAmwxieg00wYC7LM1+znXKUXriU0+ EFG8Pnw7C+8SQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R8j8g5J48z6tvn; Mon, 24 Jul 2023 16:24:19 +0200 (CEST) In-Reply-To: <83351ds9de.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:308062 Archived-At: Eli Zaretskii writes: > So the goal is to eventually support true concurrency in Emacs? Yes. > ... so these steps only make sense if the > concurrency is attainable via these measures? Yes, except that the part about thread-local point and restriction may be more generally useful. >> Consider a simple regexp search running in a thread: >> >> (while (re-search-forward re nil t) >> (do-useful-staff) >> (thread-yield)) >> >> This search will fail if another thread ever moves point or changes >> restriction in the same buffer. > > You are considering just the simplest scenario. Usually, Lisp > programs in Emacs not only read text, they also write and delete it. > What if one thread makes changes to buffer text and another thread > then wants to access it using its state variables? E.g., what do you > plan doing about the gap? will thread switch move the gap or > something? that alone is a performance killer. AFAIK, reading buffer does not require moving the gap. We only need to move the gap when buffer is changed or before copying text region from buffer to another buffer. Both such operations should be considered buffer modifications and must be blocking. > To be a step in the general direction of achieving concurrency, we > need some plan that will at least in principle allow concurrent > editing. Even if "concurrent" here means that only one thread can > write to a buffer at a time, we still need to see how this will work > when other threads are unblocked once the writer thread is done > writing. Can you describe how this will work, assuming we keep the > current design of buffer with a gap? The idea is the same as with what is already done for indirect buffers. Indirect buffer modification will affect buffer_text object in the base buffer (automatically - buffer_text object is shared). And they will also affect point position in the base buffer. The point adjustment in the base buffer is done simply by storing point as a marker. We can do the same for thread-local point positions. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at