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 08:44:17 +0800 Message-ID: <871qhjgrku.fsf@yahoo.com> References: <871qhnr4ty.fsf@localhost> <83r0pnk2az.fsf@gnu.org> <87pm57pns8.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20665"; 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 Sat Jul 08 02:45:25 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 1qHw4i-00056m-QY for ged-emacs-devel@m.gmane-mx.org; Sat, 08 Jul 2023 02:45:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qHw3r-0004oG-CD; Fri, 07 Jul 2023 20:44:31 -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 1qHw3p-0004o0-A0 for emacs-devel@gnu.org; Fri, 07 Jul 2023 20:44:30 -0400 Original-Received: from sonic310-25.consmr.mail.ne1.yahoo.com ([66.163.186.206]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qHw3n-0006is-7z for emacs-devel@gnu.org; Fri, 07 Jul 2023 20:44:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688777064; bh=0gc5fCqLY5HgOVc4xKyofcmC/mKdpHlECBdyumVXxsw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=oEA0S5zBlM4W+2TMApP0nvJJ4ge5KsMiy5gRRNnD1fQwpqqpHZkPuc3806PxUlo3hdk7X650RZZchbd64MmjpDeODwsbbf8oojun+BQ1wlRwGwhTfTJM+2OTer3P24g6ZLFsZpf0TXnl+AIvUQsDbTrrV6MlOrugvLLQc+p9gJYkYwgEuyMDtFQNM1FzSpyvEo9IHYs/zR0CXZUcbYV/MGmo6wbnRVW/Px/mlUhI1gYAGCwZxjxs3kUKBhlnZ5drdWZ8Q1MfHEBpUa8dj6FVcrfsnuvWNDWdOG/4vVLGrMVTDx2dBxrz/rCcflXVwMDAHe3D7Zc20F+nn3c1xjliwQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688777064; bh=DaWG3gfdH1/JXlUvDNwj7IJejkyKm9nrPqk3z/64yC8=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=e3qt8DLYZA4hjdlNnfr3BJFeRYRbuE2e4NgJHxOVuG+y9zOxFgCOhM167ZL6of9HX+59f3+4VBF8d15ZQBweqzy/kcjwqaJAOFs+k1Hwi6CCXkvk9fvkv8PR9c+78bDCX1OK295/2QTn6faeFrYAJ+MZfZ//kDKJ/RY8aSYVV9mjh3t5PoiyntxW4caNQoRIIJFlnFKsc7W0Znga/FNQzTXxlZ0L7pxZDqg8spTdtycLSInhSRBHzK2IKcSA0gWZWhlwKUFhCnnwCxAt2uoe4mjlBDscdcmSVd1kAX4Tvajr+ILgoD6tYX4YHSaCSbMJFlci6ANsJb48Qvtoxtaixg== X-YMail-OSG: VTUiavMVM1nZN.nQlhild_y_mcZCrdEpg8lONSlKSWmP3nWEaPfnbe1NHCCNp5N e9dDXhSBeh19zUSLDnmdQsaw3Qe0fvAk8yVzjYDrrCqPbIAHHZ4ZFag.QCodRy6GGdhQcbhfxtU2 5sCjo4sb6goDpoKRL0Z4tYVoapla_q0KcShrs85wGbubA7ot8Fb6zojPXDQe3j4EZk0EySJAiFfj IINuNdl9PPpUNg358stolRaLL6Yeh4JbsCs30AV01G9527rqGl8t71hftSChl.N_M6qfJBcZKk.D 0vsTFB95DrLkUc3j1.JllnT7hi_LZTneXvEc5BPix.BpqDHHn86Da4l4dYVc05Grvv8orlm6X9RK EZQ9W6Tb5uFD5pHgL1DSW07T1EX.lXmJsmSG5bRT_1jXIDw5pO.h4bOTrN8.XcQ05lIUP4ByEQmr NJnisUsHb1ZziPw6x.vNQMcHhd6v20fW1GhkskwZyo27GHGnJFAimAmVAU.jRTWIFxpihK5u_9LE G127mw14yx7rKhIRjHN8wxgjV5UR85kVhsKHZ1_2sDsGhW05RGRIgcoPemfvEWFkH.3lev5MmIuc QriLaFjYaaA93rUcr.Tq2x7F7LtUSepNK8399PaJs0_0rtaR1Z18UQ_TQkbnP4M.Un921ntMmavC qNZf7Yw7VZdpRqWH8UVjG264dheryWE5GYYN4fQzaueqFD6zX72dHcMyOiU8I4bCge4RezH3OEA0 NVJq_KuMAponf0qWIE0LhxR1DvjSCmiDKnQmCD2.0OwghBZu39xFrcMvnHPRMboK78JBtuGa5g0J _ObcCb7bshDVxoZ7qppvvfl00KYXY78RM6l71gzZle X-Sonic-MF: X-Sonic-ID: a88bcf1a-1b48-4e21-868c-187612f16498 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Sat, 8 Jul 2023 00:44:24 +0000 Original-Received: by hermes--production-sg3-67fd64777-kvs8m (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID aa61e3454e63d1157fb53f87abb090d6; Sat, 08 Jul 2023 00:44:21 +0000 (UTC) In-Reply-To: <87fs5zbuwn.fsf@localhost> (Ihor Radchenko's message of "Fri, 07 Jul 2023 15:31: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.186.206; envelope-from=luangruo@yahoo.com; helo=sonic310-25.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:307589 Archived-At: Ihor Radchenko writes: > So, we can hold when interrupt_input_blocked is changed until the thread > becomes main thread? IMHO there should only be a single main thread processing input and display, since that's required by most GUI toolkits. > Hmm. What about locking thread->current_buffer for all other threads? > This appears to solve the majority of the discussed problems. If you're referring to prohibiting two threads from sharing the same current_buffer, I doubt that's necessary. > I am not sure how to deal with buffer->pt for multiple threads running > in the same buffer. C functions which modify the buffer should be interlocked to prevent them from running simultaneously with other modifications to the same buffer.