From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Concurrency via isolated process/thread Date: Mon, 24 Jul 2023 16:54:21 +0300 Message-ID: <83351ds9de.fsf@gnu.org> References: <871qhnr4ty.fsf@localhost> <83sfa1gjns.fsf@gnu.org> <87r0plxbep.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23109"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 24 15:54:12 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 1qNw0q-0005nV-5a for ged-emacs-devel@m.gmane-mx.org; Mon, 24 Jul 2023 15:54:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qNw0P-0006qy-HO; Mon, 24 Jul 2023 09:53:45 -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 1qNw0K-0006qJ-CS for emacs-devel@gnu.org; Mon, 24 Jul 2023 09:53:40 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qNw0K-0005Cx-3O; Mon, 24 Jul 2023 09:53:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=U5iOjO9UuKkez/4T1+mZeBVh2WYbmPk6jfSGACDwXm8=; b=jFkAqQ8NkSiL Snx63WcmoRwx9DJ/KWdHNauWflnXpUPbVajtARQPsyFHYJyXZw9q/VlcLa7tO6sNFI8QKXLIa7IF+ CgaLEkndj+6ACBKmZJR7bcTLe1x+LC2hXTNX1f8Psb4DTBnm2SdQts+a7ZFbB+cuo0MK6itC/Y1Yn iWuevaaO1uL+GWuITgNi4QB+BvBOvQtwZWDqTh0fdhig+2yTbfBqEJ986G1H6DkPd4TPUkJ7BZE91 PoMATPix+5uzmLuESRc9Oi+xUgYSxeMUDUsX7JyO2sQUPXQR9deEQxdj5J1Ng0N9Gu4yb6KevqdeQ +NzC09M+GBiDeybEy81FOQ==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qNw0I-0008SD-6S; Mon, 24 Jul 2023 09:53:39 -0400 In-Reply-To: <87tttt1mzh.fsf@localhost> (message from Ihor Radchenko on Mon, 24 Jul 2023 13:02:26 +0000) 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:308060 Archived-At: > From: Ihor Radchenko > Cc: luangruo@yahoo.com, emacs-devel@gnu.org > Date: Mon, 24 Jul 2023 13:02:26 +0000 > > Eli Zaretskii writes: > > >> Would it be acceptable to convert buffer PT, BEGV, and ZV into > >> thread-local for current cooperative threads? > > > > General note: it is very hard to have a serious discussion of this > > kind of subject when the goals are not clearly announced, and there > > are gaps of week or two between messages. Discussing several separate > > aspects of this makes this even harder to follow and respond in a > > useful manner. > > I was initially exploring what should be done allow async threads in > Emacs. The discussion established several important global states in > Emacs that must be changed. Then, I explored if those blockers are > possible to solve. Now, I believe that all the blockers can be solved, > if we accept to leave GC and redisplay synchronous. So the goal is to eventually support true concurrency in Emacs? > However, reducing the global state will not be easy and should better be > done in steps. Ideally, steps that can be tested using the existing > synchronous thread paradigm. But the goal is concurrency? so these steps only make sense if the concurrency is attainable via these measures? > >> This way, when a thread yields and later continues executing, its point > >> and restriction will not be changed. > > > > Why is the last sentence a worthy goal? what do you think will be the > > advantage of that? > > 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. > That's why I think that having threads store their own point and > restriction is useful, even without considering that it will reduce the > global state. 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?