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: Sun, 09 Jul 2023 20:22:30 +0800 Message-ID: <87wmz9cm0p.fsf@yahoo.com> References: <871qhnr4ty.fsf@localhost> <871qhmo5nv.fsf@yahoo.com> <87bkgq8p5t.fsf@localhost> <831qhmjwk0.fsf@gnu.org> <875y6y8nlr.fsf@localhost> <87h6qhnalc.fsf@yahoo.com> <87ilax71wo.fsf@localhost> <831qhli14t.fsf@gnu.org> <87wmzdxewc.fsf@localhost> <83r0plgjeo.fsf@gnu.org> <87o7kpxapo.fsf@localhost> <83mt09gcaf.fsf@gnu.org> <87wmzbc3af.fsf@localhost> <83cz13g811.fsf@gnu.org> <87lefrbvjw.fsf@localhost> <83h6qfecxt.fsf@gnu.org> <875y6vbiej.fsf@localhost> <834jmeew2u.fsf@gnu.org> <87a5w6aa89.fsf@localhost> <838rbqcvlx.fsf@gnu.org> <87mt058l1b.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="11763"; 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 Sun Jul 09 14:23:33 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 1qITRt-0002wm-Ae for ged-emacs-devel@m.gmane-mx.org; Sun, 09 Jul 2023 14:23:33 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qITRD-0002Oy-Cu; Sun, 09 Jul 2023 08:22:51 -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 1qITRB-0002OU-4S for emacs-devel@gnu.org; Sun, 09 Jul 2023 08:22:49 -0400 Original-Received: from sonic316-20.consmr.mail.ne1.yahoo.com ([66.163.187.146]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qITR8-0002AM-DT for emacs-devel@gnu.org; Sun, 09 Jul 2023 08:22:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688905364; bh=3fHyUCqUMexNuQaoBQms8yOv+/VMY+OHByMXUOr7RFs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=Y7Fq1z5kgXan93Yi0chZtVe7KRZ20JoxWTQaawdIGko8+PV5oX8YbPjQsWItvMIWmZJ6Hx4TX8ABSNxDD2th5XSpq+ZLtOFHqHbgrLDTCT2/UnciMGjsA7fYHWU+FxhwYGIoJ1/ZVzmaZ4rXcaW3VRtpitvy4LDY7G1/ySk2ekXlicMb9CTCXdJSdREboW/ne3Se1WPQmLpDh8bDlx1E3jb19tumL2hvTADvZUI0gwI/Ruc6aTU3vixRmZltMW/JdWjW9ie0euEDGH/lDf/2jRp7BE0idiakTD/VOzaQUV0fzW5rrOgt/Zl99af9B/JW77B7IHzVVdg4Tn+A1BpWxA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688905364; bh=45Az5c+/YfBBMQc6Lnp8FSjbAVIgg0Vq7PgL2tTY3p/=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=oGIjdXAKqZ7I54SwOTgvCvbq5BMUPMS0Mpw9NzAC/34izF2Pv/Zud/youAI8bFxmbnSLf+E6JR9KLCx0lSk1HNudhyyucMP6DZXNXlZ1vevQy3TUjNYZzYNhWCmhlWVttfPZEiP0WTlAIHIToHHtJA3/WxK3O5wrMZTsp/p4uD2pk1dRCCsM7REBPyOn6gl7U0myEnl3dn9MhUdSbAmDQMmk1cIa2Di7J4LQ/4udNXhUKYGdK9WEBBEP2yWkydODwmxns9a3Lc42QxGej7CSIgd9UIJi2/fyFXBl7FZAwFI2zEitla73QzfKIAAAAjrgbX/wYD7Iy+scOLVWY/bajg== X-YMail-OSG: AfQHjgIVM1mIDX7mNsVO_Z5dsUL9mWO_viFL4.9X5_vIOiGE2JemNTdqfFwT1Fk Pw4lBy43d7kgF9QIvP2wiLTPY6rZSfhuN7FdzRKh7cW2mNSjiBEUo6Yzf6aw1_XNt9TnXLjvFEbZ .DtCDJjyoVO33oWQODWZFB6CLxrP..r5ep5e7VuClnR.u_xVk8y.uDZjFrIyJzblVGSZ.QEYnWaK prcz8XwQ7unLgSLwqytOmNa.XzH45yzKGBdLv9c9TOl7hL_EgbtKDLW4S2XUYhNH8.BpdfrcUkFy bx0JPm3hjD2PtwwfmlHj4xk_dYVP_WmBHeVolrRhn0z7ldkDde4Nu._77s32j0UxS2qvrWRuxz9G A4I0vSj9HyVe6mJTwZRrJH.2tI55mj4rgjwatG9iDlsEvcevCQ_qZV.Ul3rZtaNGvGIrF973RNEU cIxBvBPc3Uw6mPseUdrzr105XBeA1An.SIMNwzZWyq8_pF1a7M2jN3h97XgjIyxLmFDitP0nDbEX 8ssQF942tIkc6WJ_AqOTtZwRDgW6CB1jDA3Aq15NyDUCBomRogkNKCFi6H1plBKgc7KU55Sdh5N3 CBAS4jOvMiQac8rEjMavpDRvMJaQlZSjBas2b1D7zvYn7EsXFbeK8B3QLB.NugubBJQJDS0N0p6P ThX26c2MQt9h1oJ9IcHt6V82QtLWHrUQ_O424E7tlVMRfe8IT_T6B89I3UvWa7FczJxYjdWiSdqf W.QQVP1O4syTRRmoW21wznwQfeVwixrthsvDIgsWHVWSR2JaxRJTXyyqFKfk9s8LnyPlMw.o9En9 _1BAJJF9gYPWMaK80n4w1Y1Mn1zf6tRY06apycbeAC X-Sonic-MF: X-Sonic-ID: 038a0ffb-c272-428c-8818-5000c3819e55 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.ne1.yahoo.com with HTTP; Sun, 9 Jul 2023 12:22:44 +0000 Original-Received: by hermes--production-sg3-67fd64777-srcqr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e49f9d19347bd39b576df23a7ff362d7; Sun, 09 Jul 2023 12:22:37 +0000 (UTC) In-Reply-To: <87mt058l1b.fsf@localhost> (Ihor Radchenko's message of "Sun, 09 Jul 2023 09:57:20 +0000") X-Mailer: WebService/1.1.21638 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.187.146; envelope-from=luangruo@yahoo.com; helo=sonic316-20.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:307671 Archived-At: Ihor Radchenko writes: > Another thread will have its own local set of Vfoo. When that thread > switches to a buffer, it will update its local Vfoo values. So, > redisplay will have access to correct local values. How do you propose to associate different bindings for global variables with each thread? Remember that access to even a C variable in TLS is significantly more expensive than an access to a normal variable; for example, in MIPS systems, such an access results in an instruction emulation trap to the Unix kernel, and on many other systems requires multiple system and function calls. Multiple value cells will have to be maintained for each symbol that is locally bound. This alone will already be very expensive; treating all symbols this way is definitely unacceptable. > Async threads will not trigger redisplay. And they will have their own > PT, BEGV, and ZV. > > Basically, I propose async threads not to set buffer->pt in the buffer > object. They will operate using their own local excursion and > restriction. We already have window points that are distinct from PT and PT_BYTE. Adding thread-local points and narrowing would only contribute more to the confusion. The straightforward solution is rather for Lisp to avoid editing buffers that are currently being displayed from outside the main thread. >> Sure. Like I said: we'd need to lock everything. But the interlocking will be specific to the object being locked. Two threads will be able to modify the marker lists of two distinct buffers simultaneously.