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 13:02:26 +0000 Message-ID: <87tttt1mzh.fsf@localhost> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30598"; 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 15:03: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 1qNvDU-0007hN-3M for ged-emacs-devel@m.gmane-mx.org; Mon, 24 Jul 2023 15:03:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qNvCf-0001w8-4D; Mon, 24 Jul 2023 09:02: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 1qNvCd-0001vy-0r for emacs-devel@gnu.org; Mon, 24 Jul 2023 09:02:19 -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 1qNvCa-0001Fg-FE for emacs-devel@gnu.org; Mon, 24 Jul 2023 09:02:18 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 12706240028 for ; Mon, 24 Jul 2023 15:02:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1690203734; bh=pH8R1KO1lsrMuD5fM9lFaaSN2l0DTCnlCNoYs9oONJU=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=laeaYWSE0EcrZ/SJOhasRpAdZWxf8X8FiYSCs8Kq26YuP1+/ZOboKmRWPeUhKjNFS g8hIqRYw8Ys2xivZXv4MYYRNL/Q/X4Qrnt9zi+muQp6eHJmLpSdoO7aQnHeVwS1h2v H8E7ghNO5KAPGDn1LtnZ2PMLOWSWT6IaqXUO1/6Kch/m0PMxo3GHXTMG1QemmqEtXB NjVhRSVZp1HgmeWZqlz4INYREzn7hxb9DhPiskw0aOwSj8f3+GupV6riLvAanPCjts MP1dsHR5D3RH2CRO0H7WQO1IavwZvC6lDQ4u04/s/UkdEbiWX5i+MRwkO0QasrM6H+ AMDH2RxlKuwFA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R8gKx2S0Kz6twX; Mon, 24 Jul 2023 15:02:13 +0200 (CEST) In-Reply-To: <83edkxsclz.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:308055 Archived-At: 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. 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. The first step, that can also be potentially useful even if I fail to proceed far enough to get async threads, is removing global point and restriction state. >> 1. Removing pt, pt_byte, begv, begv_byte, zv, zv_byte, pt_marker_, >> begv_marker_, and zv_marker_ from buffer objects. >> 2. Adding pt/begv/zv to thread object. >> 3. Adding an alist linking buffers and past >> pt/begv/zv positions visited by a given thread. >> >> 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. The obvious (while (re-search-forward re nil t) (do-useful-staff) (save-restriction (save-excursion (thread-yield)))) won't work. So, one would have to go through awkward (let ((marker (point-marker))) (while (re-search-forward re nil t) (do-useful-staff) (move-marker marker (point)) (thread-yield) (goto-char marker))) at least. But it will yet fail if we need to maintain buffer restriction. So, the code becomes (let ((marker (point-marker)) (begv (point-min-marker)) (zv (point-max-marker))) (while (re-search-forward re nil t) (do-useful-staff) (move-marker marker (point)) (thread-yield) (widen) (narrow-to-region begv zv) (goto-char marker))) And this may still fail because of unreproducible bugs. Not to mention that we do not always know where the thread will yield. Any function may be adviced by user to contain some interactive query, which will also trigger thread yield. The above example is just the trivial regexp search. When the code becomes more complex, things gets even more chaotic and threads become simply unusable for anything that is trying to scan buffer text. 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. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at