From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Concurrency via isolated process/thread Date: Mon, 24 Jul 2023 13:53:02 +0000 Message-ID: <87o7k11kn5.fsf@localhost> References: <871qhnr4ty.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> <87wmyp1vr9.fsf@yahoo.com> <875y6939jl.fsf@localhost> <87jzup1p4x.fsf@yahoo.com> <87wmyp1oor.fsf@localhost> <87bkg11ln1.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21707"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 24 15:53:57 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 1qNw0b-0005S4-6G for ged-emacs-devel@m.gmane-mx.org; Mon, 24 Jul 2023 15:53:57 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qNvzg-0006am-44; Mon, 24 Jul 2023 09:53:00 -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 1qNvzb-0006aO-UT for emacs-devel@gnu.org; Mon, 24 Jul 2023 09:52:56 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qNvzY-00056r-P3 for emacs-devel@gnu.org; Mon, 24 Jul 2023 09:52:55 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 213C3240105 for ; Mon, 24 Jul 2023 15:52:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1690206770; bh=QV04AJGE+BPTqapeFTJNs4egRDoNzF+RCPzKLaWphkQ=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=JxErEfjA+R2gSk/CSjxA4WeVuR9CNgsUD9AyM+x4nnEkxXsIAZjCgu3MdyOouC5yT 0v3kfkjz8u6S8vbXkuC5NLg9SQdA/d9lBVaajqUe1/PwM680mmtn9LmHU3qR/pm96g PLgUJfSLJWlNW0lB7RCqImtAnRkGM4POQ0qTTpELx0tPPws2ETVw/yIXw6HX2Za6yX Z2PGiAzv+YUaszK7WN961sU3tIAARS0MgtegbV1ALUvmYU8OaW++FPJudKkJTm5Lfs 4u7wrd3vHFScCG3PaHIl5tAdiBS2B6KEQ9DzVovsxukRTgb1K9SQd6MemEcbQlJRYW SwUYSLxv+u4eQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R8hSK1YVRz6tyY; Mon, 24 Jul 2023 15:52:49 +0200 (CEST) In-Reply-To: <87bkg11ln1.fsf@yahoo.com> Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable 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:308059 Archived-At: Po Lu writes: > Ihor Radchenko writes: > >> But editing operations already loop over all the buffer markers. If a >> just dozen of extra buffer markers (one for each thread, in the worse >> case) are unacceptable, we should really do something about marker >> performance. > > It is unacceptable because it is drastically more expensive than it is > today. No degree of optimization to the marker code will eliminate this > problem. 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? >> Last time I wrote a thread code that had to work with buffer text, I had >> to store markers manually anyway. Otherwise, point position were always >> chaotic. > > What happens if another thread deletes the text that surrounds point in > the thread your code is running in? Won't you have the same problem > then anyhow? 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. Point and restriction changing unpredictably is much bigger problem in practice, because it can be triggered even without editing the buffer. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at