From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: Concurrency via isolated process/thread Date: Mon, 24 Jul 2023 17:52:58 +0800 Message-ID: <87wmyp1vr9.fsf@yahoo.com> References: <871qhnr4ty.fsf@localhost> <87zg49xfke.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4781"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , 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 11:54: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 1qNsGq-0000XX-CV for ged-emacs-devel@m.gmane-mx.org; Mon, 24 Jul 2023 11:54:28 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qNsFj-00021B-O8; Mon, 24 Jul 2023 05:53:19 -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 1qNsFe-0001zP-LF for emacs-devel@gnu.org; Mon, 24 Jul 2023 05:53:14 -0400 Original-Received: from sonic311-23.consmr.mail.ne1.yahoo.com ([66.163.188.204]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qNsFb-0005Dg-OY for emacs-devel@gnu.org; Mon, 24 Jul 2023 05:53:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1690192388; bh=xe1u4xpHj+Ak6F0Xak1UwJFms8fS0XEWnVLUPvO+am4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=gO0KYLNZU7kMvWOWqKDmxeUmYiUeufA7HrUQ2j64s+ewX1MC84uZ9OC8IpXcFeFOpXM5RFn/4nTMq5cb+CIcycl1wPPp2mSoPwyL35ar/QyiHkWE3/DkXo7jWfzvlICcvK+mIZ9bIn8Q3czS0zaxLlxEjPyFfsqS/J68/pxRE12LJjyVqyBD1/Juq2OhyXWqaPtNx923l6Sf/qgz606Lzm44qqyWAARoZAYnaQZAAgJ/zD5He2+eowVEYuaubaqwwBNVs8nfwjTFK/uo66W6rIDM/fLZwJsUhuASbgnb999xsnTJjaSl9bzP0LbvY0CQ+YVImxVfpw5o7EYF3oXMsg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1690192388; bh=poxK81qdTva3U4DSvzOMkVK/3Y5sxpKUO5xow+CIHMe=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=QFMJJ1FGKANa64C0FI3I6mhybdCV0OhV0N7oblmI/y2SC14npE0U+E3agYISvemassdW8pi2rC0fqShd4uiS0TEW215HBwwEHZvPySk8mqm6ftwiEnVABTZfYlDW/RMhWtY9r1JQAoYsZhHt9wAZh5lEZykuhHHWqm4zcOLxA7lOrSVGBXBmWG/LOSBykzp0fuCk4HkkAVVDrtQ0fQqA5y9K570QGK/wjW29Wpxo9xYoO7/k4eYHOK2+LuKQxcTY0kLBprMplb0Rf2XPjN/VAnzurhIeoVBKJ5pPyygwdyLz+Ss6Qab9rkCQEkM2B4lbdfKHDf0wHvmqVE7vaXISCg== X-YMail-OSG: .RS0f3YVM1kPj2AWkGN1XE6t1dMphkgllsCMbaJ.pMfzKucYN479X8e_GHlIUT8 .qeR2mtiYpkuwrhF_1L__xWBGEIa8dBcEPOM4HPUHjZk1oVDxVdZVTVtVwE.xIlAqQiseokE2BL9 bwWwkYQop9MrujfndcQB87yz5FXcWmVow8xmzyGQkADuDgn.tNWBogxDefZv1SX.yYzcqWnEPHkx kVjmPDEmVqlcOlz6iCfMrL3J2HVd.hlGwU8WGRXkV8N6YiKUD.PpbNyDLLdBA7FGtsp5sZDGYsfa 6v_yyH1Depv6WnpszwVKNFiWGsLP5nNYLW7ynyiBjl7dlROcGxh2mNRvHcdZiQWsf5Gins7fxMAT 4BN_tcUzbzTE8ykJ6OdWDDe.CbKnIS9pEX8IDSgABytUVeVQNlsyyH35g_d9024vZ7jCqtY6wz7o TjleiIXHBmbJ1ZynZzqBv7qZ796TEu6Oj6xr5krNrNmeTvFo2zoJOfgvR9aH2jqvTsLLize0m3xp yiM2k_n2fnF5lZ7rV3G3sHMbBYLiyh6hDveaST0Z.huCasZqyMRdbaZSSwvbpLTkNLuBhYaUVeG5 TBUT_DDNAkd3NIQXvt6fRCwoK9AIM2ss30eNBVrCMLshS6psUggCNGfLzKmwt1l386wRZqB_Z8fe vtTDU2aC0KD64q9fAwmO3SX8WLQJoDYHBu_tAF5kuROx_bk5PJf8RAJav6P7hOoO1USCUB_EHu62 Xk4ZFBZDfq_92_aMUbwN1JyT5xm28Tl4_Sy08JJkZkhfUqFnuzSscZpbl9jrVCxrQHdzp07YW1Io p8uztM596CGEik8lFtM5w8KB2RR0XiXInhyXYavx.E X-Sonic-MF: X-Sonic-ID: c197ed08-08d7-4ac5-b585-04df372e634b Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.ne1.yahoo.com with HTTP; Mon, 24 Jul 2023 09:53:08 +0000 Original-Received: by hermes--production-sg3-9dc5f54fc-v44rr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 823f5eafe771cdfb4e848e2832c27ac6; Mon, 24 Jul 2023 09:53:03 +0000 (UTC) In-Reply-To: <878rb53dkj.fsf@localhost> (Ihor Radchenko's message of "Mon, 24 Jul 2023 08:42:52 +0000") X-Mailer: WebService/1.1.21647 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.188.204; envelope-from=luangruo@yahoo.com; helo=sonic311-23.consmr.mail.ne1.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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:308046 Archived-At: Ihor Radchenko writes: > Ihor Radchenko writes: > >> 3. Current buffer, point position, and narrowing. >> >> By current design, Emacs always have a single global current buffer, >> current point position, and narrowing state in that buffer. >> Even when we switch cooperative threads, a thread must update its >> thread->current_buffer to previous_thread->current_buffer; and update >> point and narrowing by calling set_buffer_internal_2. >> >> Current design is incompatible with async threads - they must be able >> to have different buffers, points, and narrowing states current >> within each thread. >> >> That's why I suggested to convert PT, BEGV, and ZV into >> thread-locals. > > Would it be acceptable to convert buffer PT, BEGV, and ZV into > thread-local for current cooperative threads? > > I am thinking about: > > 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. It may be possible to implement this with our current yielding system. But how much do you want to slow down accesses to PT in the future, when multiple threads will run simultaneously? Operations that use and modify PT are essentially the bread and butter of Emacs, and as a result accesses to PT must be very fast. In addition to that, we already have separate window and buffer points. It would confound users even more to add a third kind of object with its own point to the mix.