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: Sat, 08 Jul 2023 15:48:02 +0800 Message-ID: <87lefqg7yl.fsf@yahoo.com> References: <871qhnr4ty.fsf@localhost> <87lefvp55t.fsf@yahoo.com> <87sfa28ura.fsf@localhost> <87cz16o8vz.fsf@yahoo.com> <87jzve8r4m.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> <87edljhmjq.fsf@yahoo.com> <87fs5zbuwn.fsf@localhost> <871qhjgrku.fsf@yahoo.com> <831qhieumz.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="9769"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: yantar92@posteo.net, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jul 08 09:48:44 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 1qI2gN-0002KU-Jd for ged-emacs-devel@m.gmane-mx.org; Sat, 08 Jul 2023 09:48:43 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qI2g0-0000nM-2d; Sat, 08 Jul 2023 03:48:20 -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 1qI2fy-0000nE-AP for emacs-devel@gnu.org; Sat, 08 Jul 2023 03:48:18 -0400 Original-Received: from sonic315-22.consmr.mail.ne1.yahoo.com ([66.163.190.148]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qI2fw-0002UF-M7 for emacs-devel@gnu.org; Sat, 08 Jul 2023 03:48:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688802494; bh=TtsicrG2wwecWzj5E8rPHfIDtEK1VX9K/YLZ1josW3U=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=VcKECH8oEvg/Az1bczyVAyBY7Olra7BCqOxHUwPa/m9jDW2NW4yh7ClX7WIIN2/x+fjx/xC5nkIJqPDqavMtNioFns+ETRxRy0j46vmiAhfEqULfNKvvDSUd76HZRIHLH1cSzVffIdPR85uV2EZlSCRPr6Zv2IpkL4YQMl1veN+ET3MNOSei8iKIVvhvORu6OnAtZglKUM4RLmBG7YRPVK+YZM+q1uJVPolz1WXJbjcVRqsZFipd5qP9N00cwlAHT7fod91NH3Xrdlz+Sx27R7uaQTIh31+2yiqdBbwTYgC/jZ8ryY8cva6plOYz5lQ9pVohIkO6n0uoI7/XHe7dag== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688802494; bh=UK7baYkwyAYOv4BGyFtm3hZWI7gpZ0TLcrP3kFjkKKF=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=TKME/wRTu/GZoDjgsGpL29hIMpw2vXDfd39mg/DbT1nbgkds7BxLAypA6+jPFgxvaBTryQS8dv1C7rlzCJgENG3TKfYb9AyFiSIN8/MQtzkxXnBFVpsdLR/e2CTiTV1rc4ZfGT74eLLltSFczbOVdBhSfc9hAbWcVeG38/pFoSgQLk0ybB22OXAkJSKn2x66QWgFvfTr/zUrmsIA/AGBv4FWOy+zZsenOQJcOm3wbnQfzxMOvfyz632kSP6ZVUiVZwmaiQ3NN7F8rm25PJgfFXFqQU+H+Mr1T/NMs5yJqnAUH8NuTaVUxFgJksyDlm1ls8ehJPHUfBjM4ev6iNxKBg== X-YMail-OSG: i3yt40kVM1l9XbnsGx3KAX5t.BthT6duYwljqR6izTKdRUeHhjncJzfhoEzH_NI dP9DQrkvz7VBEApXSo4J.QBhoMb4DDGP72HQpYZaHjpTxWVUnAEq4LcjVaNguW0JYCXpKfDRjZCK gfXpfPmcD6iCilPhr3rAlMZ9EyUQ4z8Iepwos7MVPtv7guhrB4Rpxv4WtcdhsbMvAis5EeyqB.xh e_mqo8QQmJF4yrtbiZ7EF4SGx_QqE9goK1NrTdVVUNBLcepGoLim4l8LEivgZ._JLTxzmjoeeRxI 8jkrKZ84BV6j_JFgguWYouV5bkYgrXCjQ2PcXqaT_l6oCGN.LfSasR34hg84YDL0BFIVy5qfQwTy abKkraoU87OoyF8z5z_u2m2l5ksp.Sj2yxPMNLMNbaNk44AyHfEnlL5Z7s2zRanBC7E3jGhxY34Q GiPlPj9aEq0lFgBymVQbGrxpt2S3x3Gv1h89kOEtIV7eauOr1sE4t7mHULsB7jL22pY1qNDKw7Do P_ENwk1kw7Qqd7oGOjaTy4JIaQCSKPM0CZBSq3N2WRR9EqA74aU2jIEjcfVMV4S.fdoO1O.xHINm uwVTERmaeOXU51UogdGVN2Il0.M.HXyTeFtsHH65rb2PZMojx8E9n8Wij9DKdvLELc5KMkK0HFgg vEtSymvAajn4lJw1wpIRaCcXcaJJUj942K3sVyDBoI9K4WD9CuHS6dZrav1IxOvh_w5_fL_DVZqZ 074ay.r4jMLd2xN_J7GW61cfiF8Gu8Sapq0GsbLL9GH8wMwEE.QP8bO6Pmq90R_nl3mv1dosd8qC xzmno6SyA9VTLqkMTNbIGQjq.rY7Mi3pHBN9MYO4CZ X-Sonic-MF: X-Sonic-ID: 8cd4af02-310a-4e9b-9ec1-31e78ffec404 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.ne1.yahoo.com with HTTP; Sat, 8 Jul 2023 07:48:14 +0000 Original-Received: by hermes--production-sg3-67fd64777-xdrjm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ec549b8faaf1032d39d96500e0222fe7; Sat, 08 Jul 2023 07:48:08 +0000 (UTC) In-Reply-To: <831qhieumz.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 08 Jul 2023 10:21:08 +0300") 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.190.148; envelope-from=luangruo@yahoo.com; helo=sonic315-22.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:307602 Archived-At: Eli Zaretskii writes: > That is already a problem, as long as we are talking about leaving > most of Emacs application code intact. How do you ensure only the > main thread can process input and display? A non-main thread can > easily call some function which prompts the user, e.g., with > yes-or-no-p, or force redisplay with sit-for, and what do you do when > that happens? To signal an error. Threads other than the main thread should not call such functions, which is the approach taken by most toolkits and window systems. (X being a notable exception, where every Xlib display is surrounded by one massive lock.) This will mean that most user facing Lisp won't be able to run in parallel with the main thread, but that can be fixed, given enough time. And it's not disasterous, seeing as _no_ Lisp can presently run in parallel with the main thread. > That's not enough! Interlocking will prevent disastrous changes to > the buffer object which risk leaving the buffer in inconsistent state, > but it cannot prevent one thread from changing point under the feet of > another thread. Consider this sequence: > > . thread A moves point to position P1 > . thread A yields > . thread B moves point of the same buffer to position P2 > . thread B yields > . thread A resumes and performs some processing assuming point is at P1 Lisp code that is interested in making edits this way will need to utilize synchronization mechanisms of their own, yes. > Without some kind of critical section, invoked on the Lisp level, > whereby moving point and the subsequent processing cannot be > interrupted, how will asynchronous processing by several threads that > use the same buffer ever work? And please note that the above is > problematic even if none of the threads change buffer text, i.e. they > all are just _reading_ buffer text. > > It follows that such asynchronous processing will have to be > explicitly accounted for on the level of Lisp programs, which means > thorough rewrite of most of Lisp code (and also a lot of C code). Insofar as that Lisp code is actually interested in making use of multiple threads. > IOW, we are no longer talking about some change to Emacs, we are > talking about rewriting most or all of Emacs! I think that as long as we make the C text editing primitives robust against such problems, authors of Lisp code that needs to edit buffer text from multiple threads will devise appropriate synchronization procedures for their specific use cases. For example, to parse a buffer in the background, Semantic may chose to create a new thread with a temporary copy of the buffer that is being read. Or, Gnus might do the same to fontify a Diff attachment in an article. Lisp changes can all be accomplished gradually, of course, whereas the C-level changes will have to be completed all in one go. Thanks.