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: Tue, 25 Jul 2023 08:12:52 +0800 Message-ID: <87jzuozw57.fsf@yahoo.com> References: <871qhnr4ty.fsf@localhost> <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> <87wmyp1vr9.fsf@yahoo.com> <875y6939jl.fsf@localhost> <87jzup1p4x.fsf@yahoo.com> <87wmyp1oor.fsf@localhost> <87bkg11ln1.fsf@yahoo.com> <87o7k11kn5.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="3719"; 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 Tue Jul 25 02:13:56 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 1qO5ga-0000l4-Ii for ged-emacs-devel@m.gmane-mx.org; Tue, 25 Jul 2023 02:13:56 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qO5fn-0003Ri-0U; Mon, 24 Jul 2023 20:13:07 -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 1qO5fl-0003RE-VM for emacs-devel@gnu.org; Mon, 24 Jul 2023 20:13:05 -0400 Original-Received: from sonic302-22.consmr.mail.ne1.yahoo.com ([66.163.186.148]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qO5fj-0004IU-1H for emacs-devel@gnu.org; Mon, 24 Jul 2023 20:13:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1690243980; bh=euwqeUNuzfVHDFsi0tcON3Ai2/iVcmA0gN+0xYnDKpY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=Q6zNHQrCI87+5u9m2PxinueSJc977vpb0EEVCBz3UXxJoXaUPF/EZSMhgrAu2YPvV5WrP0Fh7Kht50XrcVP+LkkVB3ZhEmvMU6tdqlgRmYe0tAkHpCFPztKOGsC91wdxI3cDTjLiECqoITMIUnG/7JYGCvw1JZYPplfn/Qf2hapTjEGYuVPYGNm/1dMhLCIzn1o7uigGAq+nsxfYwqAawTAPgjje5mBQWiYaTP1M9JaJ+cTbVtyWjo8cdCMsE4fEu7DPUlb/MruVWNTR66PdRfVw/Dbj34kVFxYtl2mZtj0JZUfdj79Nq6GgdReqDHFAvHv64HXeEcVCG85RIWZuZQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1690243980; bh=3pZ3GQ98Gv+5xhpnW8psPvLdtw+gbsZ7L9DIdDPiOkS=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=GBWEN5zR8AapWFz9BtUYZHe0Ksai7t34cAQFuj/DhChFiqHwktQ/MfmFSSJZpXF4wKVdgDTPqEyd4FfHJIatbkNPUvpxxYe/Bk39KuzCDcSis4WQYhgTcOFiPXmft4abA0TvOFgvu1avnodg4PPifxQcuy96Jo0zMYeIL6jQDmIy6Ijx12QZCE6Tyhb84NqX2xyPC3ReF6MkRiE++ol6QzLxfpR7ZaYgWh2KyQlELILKREEh/wkY8l32QqdwJ0eSC9mmCneyJfc179jJ6txEXl6qCjPKPY6AhPWMJnAyK0yCjJhUU/SMV+E9hLNvSDOocgAIMxe9CmvVCR+4dWSdDw== X-YMail-OSG: 8EaIrvUVM1mW.vfI57FjNpEiT.YTbBsDZLcAsXVR9..zM2U6KwFf7HF2LykC4WP fTql06yAxw7zatAQHDtCs7Ce0GXdsq.4XQcdZ2eQ3hhQzyWBIV8CUXypw0yShULO8vIiG0tW2e4C Ldq5EfqgrjGmzx5kmCeXpP6H0j4cJyjoSQkIXzanXEGRpL5DpW3cFEecaMOu6QwxMVh9wbJcI_DN dTzmyGkJwPrYO8UYjYFFd8JNOVdEn405pQV4_VlBZxEhTVN4bX9_mcya2lAt0FshKj0OhVIniNBF VDCBIPuPbEZIcXPbZDuVQRaMv0bsSLbLFxj9nKalRbqM2dl80QbAhdY5qjP0Fq6iZbZgFicCX7wT maKyTZ1nn5x.puL6fys5E5zlfWc0vGOqY27To7JF3Eqt2LlH3GyC6O0pvJlA2unoceRYzfZ7nPhK AYE.vutPyB7psqxVNS0qAIDkT2Hs3lktoo4L0gIXB2y4trFf4K1Z2WSKerJOOXmrKjp8hW.UBiKr B0u8IDQTDgC5KOeid2Tbp5cOX9Z7bt52V.SAinpefARXPJIinj3StdlhPpiISk1lFe92t8DpOasz 82pzL9P06jaV07JAagwttJTxm65yvseVIsSb3UJRbu5Z3NQhb5stetvanJY6TI388tP2NpZAprq7 RYkYd6awSSILAx5Y3JsJcowBefzajeRUks9BLrojgJcDoUsf2.lgpmFzF5w11hDBMt_oX9w5DCof t9q2LJ0pF1qyv61cWn4h4A6kaCqBuBdwxUrxIJsb7jzGDeAeGZvmxTl6R32KlE3bSFXDh15uyd7O 5_f1Ai5YzpJYw_cN2T3y0EG9EEUccD0S.dZz6Jpq45 X-Sonic-MF: X-Sonic-ID: b5423841-9abb-4b4a-90e8-12c831443f08 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Tue, 25 Jul 2023 00:13:00 +0000 Original-Received: by hermes--production-sg3-6b8fc8d58f-nk7q4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 199039b66df9493c0eb22fd23e7f0c93; Tue, 25 Jul 2023 00:12:57 +0000 (UTC) In-Reply-To: <87o7k11kn5.fsf@localhost> (Ihor Radchenko's message of "Mon, 24 Jul 2023 13:53:02 +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.186.148; envelope-from=luangruo@yahoo.com; helo=sonic302-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:308068 Archived-At: Ihor Radchenko writes: > May you please elaborate? > I routinely deal with buffers having hundreds of markers. > How will adding a couple of markers from threads will make things worse? See bug#64391 for a performance regression in Gnus resulting from a _single_ marker. > Usually not. The worst case could be some match being skipped, which is > often acceptable. I have seen plenty of examples because Org provides > `org-element-map' API where we allow the user function to change buffer. But Org doesn't run in another thread, does it? Besides, text matching is hardly the only tasks our users want to perform in a different thread. > Point and restriction changing unpredictably is much bigger problem in > practice, because it can be triggered even without editing the buffer. Code that believes this is a problem should devise and make use of additional synchronization protocols independent from Emacs's internal buffer synchronization.